Refining User Stories

By Roman Pichler, 18th August 2010

User stories come in different shapes and sizes. Large stories, also called epics, allow quickly sketching product functionality, which is handy for scoping a major release. But it means that larger stories have to be eventually refined and broken down into smaller, detailed ones, which the development team can implement. This post shares some tips to help you systematically refine your user stories.

Grooming the product backlog entails breaking down user stories from larger product backlog items until they are small enough to fit into a sprint. Although detailing product backlog items should be delayed until the last responsible moment, you might have to start refining a story a few sprints in advance before it can be implemented, particularly if the story is large or complex. Let’s look at how user stories can be broken down progressively.

As illustrated in the figure above, the Scrum team originally placed the epic “Compose email” in the product backlog. As it is too big and vague to be delivered in a sprint, the epic is broken down into several coarse-grained user stories. The story “State recipient” is then further decomposed into two fine-grained user stories. These are now small enough to fit in a sprint. The epic is an example of a compound story, a user story that has more than one goal. To decompose such a story, we introduce a separate story for each goal. “Compose email” is therefore broken into “State subject,” “State recipient,” and “Set importance.”

There are other user stories that need to be made smaller, including complex stories and stories with monster criteria. A complex user story is a story that is too big to be delivered in one sprint because of its inherent uncertainty or because it covers too much functionality. If it is too uncertain, we introduce one or more items into the product backlog that explore that uncertainty and generate the relevant knowledge: for instance, “Investigate JavaServer Faces as the user interface technology.” If the story describes too much functionality, we spilt it into several stories to allow an incremental delivery of the functionality. This technique is also called slicing the cake. A story that says, for instance, “Validate the user” could be decomposed into “Validate the user name” and “Validate the password.”

Stories sometimes look fine until we consider the acceptance criteria. If there are too many—more than about ten—or if requirements hide in the criteria, we need to rework and decompose the story. Here is an example: “As a user, I want to delete a text message.” The acceptance criteria state, “I can select any text message. I can remove the message text. I can save the modified message.” Not only is the second condition redundant, but the other two introduce new requirements rather than specifying acceptance criteria. This story should be split into three: a story about deleting text messages, a story about editing text messages, and another story about saving the modified messages.

You can learn more about working with suer stories by reading my book Agile Product Management with Scrum and by attending my Writing Great User Stories course.

Title picture by Ferdinand Stöhr published on Unsplash under the Creative Commons Zero license.

Article Name
Refining User Stories
Learn how systematically refine epics into detailed user stories.
Pichler Consulting


RSS Feed

Tags related to this post:

Leave a Reply

Your email address will not be published. Required fields are marked *