Photo courtesy of Pexels

Refining User Stories

Published on 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 couple of sprints in advance before it can be implemented, particularly if the story is large or complex. Let’s look at an example of how user stories can be broken down progressively.

Progressive User Story Refinement

As the picture above illustrates, the epic “Compose email” is broken down into several stories. The user story “State recipient” is then further decomposed into two more fine-grained 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” to allow an incremental delivery of the functionality. This technique is also called slicing the cake.

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, you may want to 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.”

Stories sometimes look fine until we consider the acceptance criteria. If there are too many—more than about five—or if requirements hide in the criteria, you should 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.

Learn More

Post a Comment or Ask a Question

6 Comments

  • Fredrik Holmberg says:

    Thanks for this! Am i correct that in the case of epics, we do not try to preserve the independence of User Stories. “State Subject” is not independent from the others, and it is not clear how it would deliver value until the whole epic is released. Here it seems that we are saying “Thats fine, because even the smallest solution to this Story is too big to be delivered independently”.

    • Thanks for your comment Frederik. While I agree that stories should be independent, I find that’s not always possible in practice. Similarly, I don’t think that every single user story has to provide value on its own–again that’s often impossible. But you should ensure that every story either serves a user or a business goal. If that’s the case, then I consider the story valuable. Hope this helps!

  • Koushik Mitra says:

    Who is responsible to refine the user stories? PO or the Entire team?

  • I am curious as to what happens to the “intermediate” user stories (i.e., the ones decomposed from the epic, yet get further decomposed themselves)?

    My assumption is that those user stories are actually go away and are replaced by the resultant stories from their decomposition. Is that correct?

Leave a Reply

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