process, also known as progressive requirements decomposition, might last more than one sprint. You might have to start decomposing a product backlog item a few sprints in advance before it can be implemented, particularly if the item is large and 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 Figure 1, 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.”
Ensuring Clarity, Testability, and Feasibility
Once an item is small enough, we must ensure that it is clear, testable, and feasible. (For user stories, you may alternatively apply the INVEST criteria; these suggest that each story should be independent, negotiable, valuable, estimatable, small, and testable.) A requirement is clear if all Scrum team members have a common understanding of its semantics. Collaboratively describing requirements and expressing backlog items in a simple and concise form facilitate clarity. An item is testable if there is an effective way to determine whether the requirement is satisfied within the sprint in which it is implemented. Stories must have acceptance criteria now to ensure that each story is testable. An item is feasible if it can be completed in one sprint, according to the team’s definition of done. To ensure feasibility we consider dependencies on other items, including functional and nonfunctional requirements. If a story is constrained by a user interface requirement, for instance, it must be clear what the resulting product increment should look like. If that is not the case, the team should explore the user interface requirement before the story is delivered as part of the product increment. If exploring the item requires a large effort or carries a high risk, the exploration should be tackled in a separate sprint, for instance, by implementing a throwaway prototype to investigate the user interface design.
Carefully preparing the product backlog for the upcoming sprint planning meeting is key to creating successful product. It ensures that the sprint planning meeting is effective resulting in a strong and realistic commitment. If your product backlog is not as well prepared as it should be, then start with establishing a product backlog grooming process . This allows product owner, ScrumMaster and team as well as stakeholders such as customers, users, marketing, sales and management to jointly work on the product backlog on a regular basis.