I have two golden rules for user stories. The first is that each story should be beneficial to the business. Ideally, it should carry a statement of value—of course, not all benefits have a financial value, so it is better to talk about business benefit than business value.
The second golden rule is: Each story should represent a small piece of work. While it’s tough to define how small “small” is, basically, the piece of work should be deliverable sometime soon.
In this article, I’ll discuss how to keep stories small and tasks manageable, while ensuring they retain business value.
A Balancing Act
First things first: There is tension between these two golden rules, and they often push in opposite directions. Getting stories that both exhibit business benefit and are small is difficult. The first golden rule of business benefit tends to push stories toward being larger, while the second golden rule that stories should be small tends to push stories toward being, well, smaller.
In the effort to make stories smaller, many stories lose their business benefit. When stories lose identifiable benefit, the business representatives lose interest in the stories—and in the work in general. This can also result in the technical team risk losing credibility.
When a product owner or other customer representative is part of story management and prioritization, he or she has the last say in what has benefit and what does not. Even if the technical team can see a way of breaking a story down into two independent chunks, if the requirements specialist cannot see benefit in each chunk, then the chunks do not have value and should not be split.
I know a team who split a story to preserve the system state into “Save data” and “Load data” stories. This makes sense from a technical point of view because each is an independent piece of work. But the business analysts said, “Neither has value on its own; only the whole has value to us.” Thus, the stories did not stand as good stories. The technical team is within their rights to split the “Store and restore system state” story into one “Save data” task and a second “Load data” task and then implement them, but they should not be made into separate stories.
The technical team could engage in discussion with the business analysts and point out that simply being able to demonstrate the system saving the data could have business benefit, by showing progress to a customer. But the business analysts have the right to stick to their original position.
How Small Is “Small”?
How small is “small” will depend on many things, but as a rough rule of thumb, “small” should mean less than two weeks’ elapsed effort—that is, from accepting a story for development until it is ready for delivery should take less than two weeks (ten workdays). This may be a generous definition; I know people who think two days is a long time.
Of course, there are exceptions, but they should be exceptions. Indeed, I would hope that most stories end up delivered a good deal sooner than two weeks.
However, the goal is to always strive for smaller stories. In terms of process, this is preferable because smaller pieces of work flow through a process more easily. In terms of forecasting, it is better because smaller requests can be accomplished more quickly, which results in a smoother flow and greater predictability.
Business benefit increases because delivering work sooner generates benefit sooner, so the return on investment is greater.
With smaller individual stories, it is also easier to spot risks and identify troublesome work. Risk is further reduced because when work is flowing smoothly, the system as a whole is less prone to disruption.
Finally, the impact of encountering a problem is less because the affected work is smaller. Failure of a hundred-thousand-dollar piece of work costs a hundred thousand dollars, but failure of one of ten ten-thousand-dollar pieces of work of work is only ten thousand dollars.
So, What’s the Right Size?
Unfortunately, there is no one right size for every user story. The size of a story depends on a number of factors, and the right size for one team may be too big or too small for another team.
One reason is that the size depends on the knowledge the team creating the software has. A team who has been working in the same domain for a long time will instinctively understand a lot more than a team new to a domain. They will need less explanation of what needs doing, and they will know the language, domain, and context of the story.
I once knew an outsourced development team working for an airline. Few on the development team initially had experience in the travel industry at all, let alone the airline business. The lack of experience meant they needed more help from the customer team and lots of detail on stories, and the stories were so small that it was difficult to see the business benefit.
Contrast this with a team who has worked directly for an airline for years. Faced with the same user story, this team will immediately know the industry terms and language, plus many of the airline’s existing standards for things like passenger name length, punctuation, and more. Such a team can work with less detail and bigger stories.
Story size will also vary depending on the technologies in use. It appears that teams working in the more modern, high-level languages, such as PHP, Python, and Ruby, can handle bigger stories than those working in older system languages such as C, C++, and Java.
Iteration length and overflow rules will also play a role. Teams working on four-week iterations will be more willing to accept bigger stories, while those working on one-week iteration will challenge bigger stories more often. Given the advantages of small stories, the pressure created by shorter iterations can be beneficial.
Practice Makes Progress
Writing stories that are both small and beneficial is hard. It takes skill and practice, and it doesn’t happen overnight or by attending a training course. (It won’t even happen just because you read this article.)
Therefore, especially for people who are new to writing stories, every opportunity should be taken to make stories smaller. You will make some mistakes, but those mistakes will help you learn. Just don’t lose sight of the goal of keeping stories small and tasks manageable—while retaining business benefit.
User Comments
Very well explained! All our new members struggle with this. My favorite way of resolving the choice of how to cut the story scope to size is to question if the end story gives a clear slice through the application/service from input to output. Thus, a good story is often as small as entering a value(s) on a create/edit form and then viewing it on a profile or summary page.
Of course, a lot of our work requires developing APIs for accessing complex product data or conducting B2B transactions. Sizing that work seems different but not too much, you can still imagine and plan incremental additions of information to the data feed or iterate over transaction validation provided the increments form logical chunks of data or processing - like checking for nulls in required data first, then validating data values. These are demonstratable checkpoints and when we work at that level - with developers and testers helping decide the story objectives - we get an amazing amount done quickly.