Generally speaking I encourage people to make their user stories smaller, not bigger. But I will long remember an excessively heated argument many years ago with my former colleague Mat Wall in which he was adamant that I was going too far by insisting on stories which where too small. In that case he was probably right. So what is the right size for a user story?

I would (still) say smaller is better. But it’s important to understand why, and therefore why smallest is not necessarily best. Here are some considerations when sizing stories:

• Deliver value early. This is the essence of agile projects, and it should be the essence of our user stories. Get some genuine value out there sooner rather than later (and then you can add to that value with a subsequent story). There are different kinds of value…
• End user value. Getting out a little value sooner to the end users is usually better.
• Value to the project. By putting out smaller stories you are collecting more data points to track your progress more accurately.
• Reducing uncertainty. You don’t want surprises. By tackling the most uncertain aspects sooner you will be in a much, much better position to do something about them while you’ve still got time. See my other blog post on value first versus risk first.
• Tech value. Sometimes a single piece of end user value requires a lot of tech work to get there. Then it’s a case of refactoring and refactoring until it’s trivial to add the new functionality. In those cases I’d look to the team to release the refactored code along the way, with the requirement that every release must leave the codebase in an overall better state than it was before. It’s the boy scout rule of “always leave the campsite cleaner than you found it.” So even those interim steps have added value, albeit to the team (and codebase) internally. And this is necessarily bound up with…
• Walkawayability. See elsewhere for a more complete discussion of walkawayability. You always want to be able to walk away from your project at any time; otherwise you’re essentially holding your stakeholders to ransom. This is a critical test of agility.
• Feedback. Most of the above enables feedback. Once you’ve done something you get feedback from it, and it’s best to order the work to get the most valuable feedback earlier. You maximise that feedback if you go all the way to release. The earlier you get feedback, the more responsive you are.

If you think I’ve missed something there do let me know.

Most of the considerations above mean that stories should be smaller, but some others mean there’s a limit to which that makes sense. And some assumptions may not be relevant to your situation—for example, if it’s inconceivable that the project might be foreshortened, or if there really are no uncertainties in the work. But these situations are rare. And if you’re suitably imaginative you can usually get the best of all worlds.

Photo by Whatknot