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.