RSSGrooming the product backlog entails decomposing larger product backlog items until they are small enough to fit into a sprint. This process, also known as progressive requirements decomposition, might last more than one sprint. Although detailing product backlog items should be delayed until the last responsible moment, you might have to start decomposing a story a few sprints in advance before it can be implemented, particularly if the story is large or complex. This allows gathering the necessary feedback from customers, users, and other stakeholders before detailing the item. Let’s look at how user stories can be decomposed progressively.
Decomposing User Stories
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 decomposed, 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.
Find out more about working with the product backlog effectively by reading my book Agile Product Management with Scrum or by attending my product owner course. User stories are comprehensively described in Mike Cohn’s excellent book User Stories Applied.
