Relieving Agile Tension: How to Write Small Stories That Still Have Value

There are two practical goals for user stories: Each story should be beneficial to the business, and each story should represent a small piece of work. However, there is tension between these rules, and they often push in opposite directions. This article discusses how to keep stories small and tasks manageable, while ensuring they retain business value.

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.

User Comments

1 comment
mhpries's picture

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.


July 17, 2015 - 12:27am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.