Many of us agile coaches are familiar with the INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) criteria that stories should meet after refining them. Almost a maxim if you will, supported by text book examples in the classroom. Participants mostly get it in principle but are they really connecting INVEST to their work context as they sit in the classroom? Probably not the majority, I think. Some do ask questions offline outside the class which is great showing signs of their trying to make the connection to the nature of the work. Here are some questions especially from people working in highly componentized Scrum teams (an oxymoron there!) and my point of view and answers.
- What exactly is meant by “Independent”? How can any story be truly independent?
- Answer: True, many stories have to come together for a feature, maybe across many teams. But the intent is to produce “something” meaningful to review with the Product Owner and other stakeholders to get feedback on by itself so that it can get to a DONE state without depending on another story to be completed and integrated. While that is good as a concept, with highly componentized teams, synchronization of dependent stories across team within a sprint is indeed challenging. So, the practical interpretation “Independent” is really something “demonstrable” for feedback at sprint review regardless of the dependencies.
- What is “Negotiable”?
- Answer: Well, why should it be? The intent is to leave space open between the PO and the developers so that there is a prod for innovative thinking in solution approaches, clarity of scope boundaries and not just negotiating the size of the story. Sometimes, Scrum teams tell us, “The architect is an expert and he has spelt out this technical story in such detail; so, we know precisely what needs to be done”. Well that maybe, in many cases. However, making that as a rule for all stories discounts the possibility of the team collectively being smarter and more creative than the architect. Even more important, it also limits the team from continuously learning from the negotiations with the architect.
- How valuable is “Valuable”?
- Answer: No doubt, the ultimate value at a feature level would be very evident and hence how the story is fitting in the overall feature jigsaw should also be evident; it is more the “inherited” value of the story rather than something absolute and independent. So, the value in this case for component teams is not easily articulated from a user point of view; but surely, the value should be evident for the consumers of the story in other related component teams.
- How about estimable?
- Answer: This is an easier thing for teams to understand; anything “big” is not easily estimable and so, divide and conquer. There is, of course, the “no estimate” school of thought; for example, the “no estimate” team being able to just look at the story and be able say whether it can be done within a sprint or not, hopefully keeping the DONE criteria in mind. That is more in the case of higher maturity teams. Teams early in the agile journey, however, would significantly benefit from story-level relative estimates and even task breakdown and effort estimates. Over time, these teams gradually wean themselves away from task breakdowns and effort estimates.
- How small is small?
- Answer: Well, there are several well-known thumb rules here. First of all, at one extreme, the story should not end up being a task – a task being something that an individual works on whereas, a story is amenable for one or more persons to work on; another thumb rule is whether the story can reach the “DONE” state in about half the sprint length (say, on or before day 5 of a two-week sprint). At the other extreme, the upper bound can be stories that tend to be more two jumps relative to the reference story; they would of course need to be spilt in some manner.
- What is “testable”?
- Answer: Again, in domains such as embedded software development where the teams are often component-based, it is not always possible to fully test stories beyond some basic unit test; so, there is a long “tail” of integration and acceptance tests beyond the sprint where the development of the story is completed; so, the story may not be fully DONE in the classical sense till the entire integrated testing cycle is complete. But this does mean separate dev stories and QA stories; it means that the approach to testing also needs to be thought of in slices. The situation can also be alleviated improved end-to-end test automation, shifting left etc.
So, there you have it. INVEST is a good concept but its value should be realized by interpreting it in context. Needless to say, Scrum Masters and coaches should go beyond the classroom explanation of it and help teams in the interpretation and realization of its value on the ground.
Look forward to your comments.
