I started studying Scrum formally using the 2016 and 2017 Scrum guide for my PSM I certification. The guide does not highlight Product Backlog Refinement as a formal ceremony. However it seems to be essential for Sprint planning. The guide only indicated that Product Backlog items are deemed “ready” for selection in a Sprint Planning.
Scrum has several prerequisites to work effectively. Scrum guide assumes that the product vision and the team have been established, the budget and duration has been negotiated, and that there is an existing product backlog where the top most backlog items are implementable in the next sprint.
Without establishing these prerequisites, Scrum will be incorrectly implemented and the benefits will not be achieved even at the first few sprints. In our first attempt to Scrum, we started dividing the project into time-boxed sprints. We have divided the features and scope per Sprint. However, since the Product Backlog items were not refined and analyzed in detail, we ended up having mini-waterfalls per sprint. We spent a lot of time defining, analyzing, splitting, estimating, and breaking down the features selected for the sprint. This resulted to over-optimistic estimates and difficulties in producing value per sprint.
An ideal Product Backlog is not bucket of ideas or action items from stakeholders. It is necessary for the Product Owner to regularly refine and groom the Product Backlog to keep it up-to-date. The Product Owner removes stories that are no longer relevant, applies the latest inspect and adapt information to the backlog items, and refines top level backlog items at least 2-3 sprints ahead into a READY state.
Definition of Ready
What do we mean when a Product Backlog item is READY?
- It is CLEAR : everyone understands the WHAT and the WHY of the Product Backlog item
- It is SMALL: the product backlog item can be implemented in 1 sprint that complies with the definition of Done
- It is TESTABLE: acceptance criteria can be defined
A good user story or requirement should pass the INVEST Criteria of Bill Wake.
- I: Independent, avoiding dependencies and overlaps
- N: Negotiable, specifies the WHAT and not the HOW. Backlog items are negotiated and clarified between Product Owner and the Development Team.
- V: Valuable, has value to customer in terms of increased revenue, avoiding cost, or improve service (IRACIS)
- E: Estimable, stories should have enough information for customers to rank and schedule priorities and help make decisions
- S: Small/Scalable, it can be done within a sprint. Start with smallest stories first then scale up.
- T: Testable, understood well enough that tests can be written
The Agile team can define their Definition of Ready. It may include team-specific checks such as the ones below:
- User Story Card (Ticket) is available
- Story size can fit in the teams velocity and sprint length
- At least 3 and at most 5 acceptance criteria have been defined
- Dependencies have been identified and “connected” so that stories can be synchronized
- UX Wireframe/Mockups have been defined
- The Development Team who will implement the user story has been identified (in case of multiple teams)
Advantages of Product Backlog Refinement Meetings/Events
- Reduces uncertainty and unknowns. More refined stories have more accurate estimates
- Dependencies are discovered sooner
- Shared knowledge of the team on the Product Backlog Items
- Reduces the time for Sprint Planning
- Makes the product backlog clean and orderly
Product Backlog Refinement Process/Event
- The Product Owner is responsible for ensuring availability of READY product backlog items. Refinement of Product backlog items is a collaborative effort between the Product Owner and the development team as long as it does not exceed 10% of development time.
- The Scrum Team should schedule regular product backlog refinement
- Similar to Scrum Events, regularity removes complexity
- Remember that the Product backlog items being refined are 2-3 sprints ahead, not the current product backlog items selected for the current sprint (Sprint Backlog)
- In the Blog Post of Stephan van Rooden, Product Backlog Refinement Explained, Defined useful flowcharts for refinement activities.
- Flowchart before the Refinement Meeting: any idea to be included in the Product backlog undergoes the following check items: Is the WHY clear? Is the WHAT clear? Does it contribute to product vision? Does it add value? If all answers are YES, write a Product Backlog Item
- Flowchart during the Refinement Meeting: Set a 10-minute timebox for each Product Backlog item for refinement. Each Product backlog item will undergo the following steps: Dev understand the WHAT and WHY and has idea on HOW to create it. The team should be able to estimate it. When the effort < benefit and meets the READY criteria, it is included in the product backlog. For those that exceed the timebox, either perform a spike to be included as product/sprint backlog item or set another 10-minute timebox.
- In a blog entry Why do Product Backlog Grooming?, ScrumCrazy.com suggests a Three-step Product Backlog refinement,
- Stakeholder Product Backlog Refinement: PO and Stakeholder collaborates to refine and order product backlog items
- Informal Product Backlog Refinement: PO with 0 or more development team members or stakeholders will refine and order the product backlog items.
- Weekly Team Product Backlog Refinement: The Product Owner presents the backlog items, the team asks questions, and the team estimates them.
- Activities during Regular/Weekly Product Backlog Refinement meeting
- Splitting Product Backlog Items
- Establishing acceptance criteria for Product Backlog Items
- Estimating Product backlog Items
- Checking whether the Product Backlog items for the next 2-3 sprints are READY
- Identifying any need for Spike Product Backlog Items
Tips on Product Backlog Refinement
- 10 useful strategies for breaking down large User Stories (and a cheatsheet), stories can be broken down vertically
- Workflow Steps
- Business Rules
- Happy/Unhappy Flow
- input options / platform
- data types or parameters
- test scenarios / test case
- ‘optimize now’ vs ‘optimize later’
- browser compatibility
- Scrum Product Ownership Book by Robert Galen talks about the following rules of thumb/best practices
- 20/30/50 balanced backlog
- 20% of the Product Backlog are ready to be implemented
- 30% are larger (8-13-20 point) stories or epics targeted for the next release point
- 50% are large epics or themes – some ideas of product direction
- 70% versus 30% Heuristic
- Prior to entering a Sprint, product backlog items should be defined up to 70%. Stories are intentionally incomplete, they are a promise of conversation
- 30% of the story is cleared up within the Sprint. This is a primary reason why Product Owners should be available to clarify Product Backlog items during the sprint execution.
- Seeding the Product Backlog
- Seed the product backlog with data in order to drive collaboration and feedback.
- The Product Owner may already include information such as story descriptions, acceptance tests and estimates that are either wrong or outrageous to get the team’s attention.
- 20/30/50 balanced backlog
- ScrumCrazy.com in the article Tips for Effective Backlog Grooming gave 18 for backlog grooming
Please share your tips in the comment section below.
– Agile Pinoy