What do you do during Product Backlog refinement? How do you prevent discussions going off track or in too much detail? Who should be there? When do you estimate? In this blog series, you will get some good practices and guidance for having better, more effective and more vivid Product Backlog refinement. This series will consist of three posts:
- Before you bring an item into a meeting
- What do you typically do during a meeting focusing on refinement?
- Facilitating a meeting on Product Backlog refinement
The refinement meeting
The scrum guide states:
The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Developers.
In practice, this means that most Scrum Teams plan three time slots of each one hour, throughout the sprint where they spend time with the Product Owner and stakeholders. This should be enough time for a Product Owner and the Developers to create a flow of items in a ready state. Ideally, a Scrum Team has 2 sprints of ‘ready’ work on the product backlog so if a product owner goes on a holiday or falls ill, the team can go ahead. We find teams struggling to gets enough work in a ready state for the upcoming sprint.
Vague items being brought into Product Backlog refinement and the Developers getting caught up in discussing any possible solution are signs of refinement gone wrong. Such discussion are consuming the energy of everyone in the meeting, including those involved in the discussion. When facing this teams often set a 10 minute time box to discuss a Product Backlog item. If after 10 minutes there is still no direction of a solution, the discussion is stopped and the Scrum Team decides what to do next. For example, it might be that the Product Owner needs to verify with his stakeholders some assumptions or that the Developers need to do some homework on the possible solutions.
Sometimes it might be useful to involve stakeholder in product backlog refinement. When stakeholders and the Developers are in direct contact with each other, it prevents both sides from making estimates based on assumptions.
Spikes
Spikes finds their origin in Extreme Programming and are described as ‘A story or task aimed at answering a question or gathering information, rather than at producing shippable product’.
So during Product Backlog refinement the Developers can decide to create a spike. This spike will be added to the Sprint Backlog of the current Sprint. Preferably will bring back a result before the next meeting so the item can be brought a step closer to being ready.
Two characteristics of a spike:
- Have clear objectives and outcomes for the spike. Just like any other sprint backlog item
- Be timeboxed. Start with the timebox of one hour and after that decide if you need more time.
The biggest risk when introducing spikes to a Scrum Team is that they embrace this type of task as a tool to create detailed plans and designs. A spike is an exception, not the rule!
Activities during Product Backlog Refinement
Performing the activity of Product Backlog Refinement is of primary interest to the Product Owner. It is up to this role to have an effective Product Backlog refinement. For each item they decide to bring forward during refinement they need to have a clear idea of what they would like to achieve for this item. In the movie by Henrik Kniberg, ‘Agile Product Ownership in a Nutshell’, three things you typically do during Product Backlog Refinement are mentioned. Slicing, estimating and writing acceptance criteria for Product Backlog items in collaboration with stakeholders.
Slicing
As stated earlier ,the purpose of Product Backlog refinement is to get Product Backlog items in a ready state. This means that an item should be small enough to be picked up in a Sprint. This may sometimes take some creativity to achieve. The story splitting cheat sheet is a great tool to help teams with exploring possibilities for splitting items. To practice slicing there is a great game to have teams see the value of splitting stories, Alistair Cockburn created the Elephant Carpaccio exercise. A word of warning, some teams have figured out how to slice items, they tend to slice up beyond the point it being necessary to make an item smaller. This is the time where a Scrum Master of Agile Coach should intervene and explain the team the purpose of slicing.
Estimation
One of the most debated activities when teams apply the Scrum Framework is the point of estimation. Scrum simply states that items should be estimated, however how to estimate is left blank. Whatever work best in your situation.
First, let’s be clear, you can always estimate! Even if something is unclear, you can come up with an estimate (most likely something big). Assigning an estimation is not the same as getting an item in a ready state. Product backlog refinement would be a lot less difficult and time-consuming, if everyone involved agrees that an estimation is by default incorrect. It doesn’t matter which technique you apply. If you cannot get past that point, any technique will result in the same frustration. If you do get everyone to agree on this, then you might consider the following techniques.
- T-shirt sizing
- A great technique for quickly estimating an item. It’s fast and easy to use. Everyone has an idea of the concept of small, medium or large.
- Magic estimation, a technique for fast estimation of multiple items
- I would recommend reading this blog on how to do this activity.
- Planning poker
- Best known technique for facilitating team estimation. Planning Poker has its origin in the widepand delphy method and was made popular by Mike Cohn. A time-consuming technique but very effective.
Acceptance Criteria
Adding acceptance criteria to a new feature is not new, we have worked this way for decades. This activity is done together with the entire Scrum team, preferably during Product Backlog refinement. The level of detail when writing acceptance criteria depends on;
- The item at hand
- The level of knowledge and experience of the people involved
and most of all
- How good the Product Owner and the Developers interact.
Product Backlog refinement meetings can be very efficient when the Product Owner more or less knows the level of detail the Developers need. Just using the user story template can be enough for the Developers to have an item in a ready state. A Product Owner should spend less time on writing acceptance criteria and more time on frequent inspection and adaption when the item is in development.
From my experience this should be enough to get started with product Backlog refinement. In the third, and last, blog, I will share some insights in how to facilitate a Product Backlog refinement meeting.