Many teams that try to implement agile processes report that they often don’t observe the promised results. This may have many causes, but one often overlooked one, is that stories tend to get “inflated” as day-to-day pressures start to mount. I am not speaking about point estimates, but the story scope itself. Trying to do too much in a story compromises flow, increase cycle time and can frustrate the team. An agile team that strives for continuous and interactive delivery should try and revert that tendency.
Usually in agile, we tend to look at Bill Wake's I.N.V.E.S.T. as the golden standard for good user stories. A quick refresh of what INVEST means:
Independent – achieves increment in value immediately
Negotiable – not a static contract, can be changed by a conversation
Valuable – improves the way the product is experienced
Estimable – can be sized compared to other stories
Small – the smallest possible increment
Testable – you know when it is done and that value was achieved
As useful as it can be, it can also set you up for trouble, as it sacrifices relative importance in order to maintain the acronym legible. “Independent”, for instance, is no more important than “Valuable” (and probably much less), therefore, we can't really go about it as a check-list from top to bottom, because if you do, you may sacrifice story quality to make it independent, which would be bad. I’ve found it essential for the story to be valuable and testable. Even though the client or team may insist in playing the story, they need to understand why the story is so necessary to begin with, and when it will be considered “done”. Next is trying to balance independence and size, as they are really the determining factor of stories. It is a tough balance to achieve, but it is well worth it. To be honest, I hardly ever look at the other two characteristics (negotiable and estimable).
How do large stories hurt?
Error-prone
Besides the obvious losses in flow (as larger stories take longer to complete), stories that are too big can cause a number of other problems. It is more likely that important details will be missed if there is too much in the story. In fact, it is not uncommon to see the total number of acceptance criteria go down when a story is broken up into smaller ones, because complexity is handled iteratively. Imagine trying to describe all breeds of dogs in a single piece of prose instead of in a hierarchy. This impacts developers as they code the stories. If a story has dozens of criteria to meet, it is more likely that one will be missed, than if there's only a handful to consider.
Dependency Hell
Scope control and prioritization too are much easier with small stories. If I have a story that displays “name”, “picture” and “description”, the only way I could remove it from scope is if I won't need either of the three. If they are in different stories, I could opt for doing two of three now and postpone or remove it from scope completely. When writing a story there's a temptation to group simple things “to make it easier” , but this brings the implicit assumption that all three are equally simple and the cost of doing them together is the same. If this is not true, a team can lose a lot of time before realizing this is holding them back. It would be much better to deliver three stories in quick sequence, than to be blocked on a large one. If this large story has other dependencies (more likely only a small part of it has it), you can face even worse consequences!
Bad forecasting
Besides that, because of regression to the mean, estimates for many small stories together can be more precise for the same total scope. Much like when we roll a dice a hundred times, we can expect a more homogeneous distribution of results than if we roll it ten times, when you estimate a hundred stories, it is natural to have some random error, in some for more, in some for less, but the larger the number of stories, more likely it is that the total sum be close to reality. It is also understandably easier to to estimate smaller stories, as all details can be considered in one go than it is to estimate larger ones, where criteria will be more complete.
All in all, smaller stories tend to be more precise, allow for better progress tracking, allow the team to change its mind quickly and increase the team’s confidence in delivery.
How small is small?
To write smaller stories, there are a few tricks that can be used to reduce anxiety of having things that are “too small to matter”:
- Remember that in in agile development with continuous delivery, going to production is a business decision – not a technical one – therefore, business can decide to wait until all pertinent stories are done before releasing it to production (or can change its mind and go live before!)
- Split stories into thin vertical slices across all layers (like a cake). Even if it looks like more hard work, in practice, the independence gained by doing so allows future stories to iteratively improve in implementation. Thus reducing the pressure to “make it perfect the first time”
- Do not describe implementation, but the expected value. Usually a well-understood problem ends up being easier to solve than the original designed solution. Remember to look for the minimum incremental value that can be tested, as small as it may be.
- Don't worry if in the beginning of a project stories are bigger. This is the period, that in order to reduce risk, teams implement the more crucial functionality. The important thing is to make sure that, as the project progresses, stories become smaller and smaller
Now go and look at your backlog and ask yourself which stories could be smaller. There's no reason why not give it a go!