Want the quizzes to work? Click here for the HTML5 version.

Tweet

Module 2: Backlog Refinement Meeting (aka. Backlog Grooming)

• When do we groom the product backlog? What is the purpose of the meeting? Who participates?
• Example epics.
• Example Bill Wake INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) user stories.
• Example acceptance criteria (vs. definition of done).
• The roles of the Product Owner, Scrum Master, and self-organizing team in backlog refinement.
• Timeboxing the meeting.
• Relative effort estimation game (aka. Mike Cohn “Planning Poker”) variation with T-shirt sizes and story points.
• Scope control: Focusing on high business value work, deferring low ROI work, force-ranking the Product Backlog.
• Estimation vs. commitment.
• Gratuitous “Dukes of Hazzard” chase scene with banjo music.

The Scrum Training Series is provided free of charge and used by thousands of Agile practitioners, coaches, and trainers around the world.

Contact Michael James via Twitter.

Script without illustrations.

Scrum Reference Card Excerpt: The Backlog Refinement Meeting

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

Notes on Estimation

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.

Notes on User Stories

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 and these suggested epic splitting steps.

Agile Estimation Frequently Asked Questions (FAQ)

• Q: Being a scrum master, how can I make sure that the developer/QA won’t give a too large estimate? Usually, if they are lazy, they can estimate that they need more time than the realistic to do the tasks so that do less. [NOTE: I am quoting the question verbatim. –mj]

  A: Let’s examine the misconceptions behind your question:

  Is it the Scrum Master’s job to manage people to make sure they’re not being “lazy”? No, the Scrum Master creates an environment for team self organization.

  Are individual task estimates necessary in Scrum? No, during Backlog Refinement teams estimate their collective effort to complete Product Backlog Items (PBIs) (if they estimate at all), not tasks.

  Do estimates matter in Scrum? Not really — teams should use their gut feel during the Sprint Planning Meeting to decide which Product Backlog Items (PBIs) to attempt in a Sprint.

  Is laziness the main reason creative and analytical work takes longer than managers think it should? No … if you actually think this I’d encourage you to try doing technical work yourself some time. Many things cause development to get behind schedule, including failure to control the scope (a Product Owner responsibility), unrealistic external commitments (a Product Owner responsibility), excess multitasking and distraction (a ScrumMaster responsibility), and poor technical practices (everyone’s responsibility). If your first reflex is to assume these problems are caused by developer laziness, I fail to understand why your team would choose you as their Scrum Master.