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.
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.
