The Scrum Training Series is provided free of charge by CollabNet, Inc. and used by thousands of Agile practitioners, coaches, and trainers around the world.
Script without illustrations.
Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. Teams have found it useful to take a little time out of Sprint Execution — every Sprint — to help prepare the Product Backlog for the next Sprint Planning Meeting.
In the Backlog Refinement Meeting, the team estimates the amount of effort they would expend to complete items in the Product Backlog and provides other technical information to help the Product Owner prioritize them. (The team should collaborate together to produce one jointly-owned estimate for an item.) Large vague items are split and clarified, considering both business and technical concerns. Sometimes a subset of the team, in conjunction with the Product Owner and other stakeholders, will compose and split Product Backlog Items before involving the entire team in estimation.
A skilled Scrum Master can help the team identify thin vertical slices of work that still have business value, while promoting a rigorous definition of “done” that includes proper testing and refactoring.
It is common to write Product Backlog Items in User Story form. In this approach, oversized PBIs are called epics. Traditional development breaks features into horizontal tasks (resembling waterfall phases) that cannot be prioritized independently and lack business value from the customer’s perspective. This habit is hard to break.
Agility requires learning to split large epics into user stories representing very small product features. For example, in a medical records application the epic “display the entire contents of a patient’s allergy records to a doctor” yielded the story “display whether or not any allergy records exist.” While the engineers anticipated significant technical challenges in parsing the internal aspects of the allergy records, the presence or absence of any allergy was the most important thing the doctors needed to know. Collaboration between business people and technical people to split this epic yielded a story representing 80% of the business value for 20% of the effort of the original epic.
Since most customers don’t use most features of most products, it’s wise to split epics to deliver the most valuable stories first. While delivering lower-value features later is likely to involve some rework, rework is better than no work.
The Backlog Refinement Meeting lacks an official name and has also been called “Backlog Grooming,” “Backlog Maintenance,” or “Story Time.”
Estimation is less important in Agile development than it is in traditional development. When the product is kept in a shippable state at all times, large items are split into small high value per effort items, and work is constantly prioritized, getting estimates wrong means omitting the lower priority features rather than missing a delivery date entirely (or shipping a poorly-tested product). Most teams that have excessive angst around estimation would benefit more from improving their technical practices, backlog refinement, and prioritization.
While this video example used T-shirt sizes and corresponding powers of two, it is also popular to use Fibonacci number sequences such as 1, 2, 3, 5, 8, 13, etc. If a team's already using Fibonacci numbers I don't disuade them from that, but I don't teach it this way to new teams because I find it an unnecessary distraction. Our own team tried both and found powers of two more representative due to the human tendency to underestimate large items.
Some experts recommend an extremely simplified form of estimation: either an item is small, or it needs to be broken down.
User stories seem very simple, but most of the ones I see in the field and by training participants are still written from a traditional mindset rather than thinking in thin vertical slices. "As a developer, I want an data-flow diagram so I can understand the code," is not a well formed user story. The data flow diagram may be an appropriate Sprint Task related to a user story, but I'd drop the user story-like language to prevent confusion.
We're really looking for tiny customer-centric features. They're in there. If your team is struggling to find them, try this epic splitting exercise.