What is Product Backlog Refinement?
One of the concepts that, when you hear it for the first time, needs some explanation is Product Backlog Refinement. Understandable when you worked in a plan-driven approach for a long time, where you first analyze, then design, build, test and finally run a product. This concept of refining makes some sense, but to plot it in that original process then seems hard.
So let me start with an example. Your Product Owner has a big idea for the product that she placed on the Product Backlog. In order to turn this into a feature, to start developing it, this idea needs sharpening. The team needs to understand it, so they collaborate and talk about it. They get input from the PO and possibly other people. They talk about it just enough to understand the value, the effort and how to validate it.
One definition of refinement is pretty spot on if you ask me: the improvement or clarification of something by the making of small changes. Together you collaborate around the work that you will do in the future. You clarify the intent by adding more detail and work together to define scoping. Product Backlog Refinement is all about a shared understanding between Product Owner and the Development team.
During the Sprint the Dev Team has full focus on the Sprint Goal. Full focus on delivering a done increment. However, there needs to be some time to discuss new ideas, problems or improvements in order to get to something that we can deliver in a next Sprint. We collaborate around the why and what of a problem or idea, we clarify and sharpen, until we decide we know just enough to start working on this.
Why we do refinement?
Refinement is about creating a shared understanding (between PO and DT) of the value and intent of the items on the Product Backlog. Shared understanding sounds good, but why is it so important?
Some scenarios I have seen in practice:
We don’t do refinement.
In Sprint Planning the Dev Team just sits blank at first. After some explanation of the Product Owner discussions start taking place about the content, the value, the size and the order of the work. In the end, we just pull some items of the Product Backlog to start working, because the timebox expires. There is no belief in the reliability of this plan, or there is no plan at all.
We do too little refinement as a team.
Sprint Planning in this case often seems to start fruitfully. The items on top of the Product Backlog look relatively clear and the Dev Team feels confident to pull these in the Sprint. Then, going through item X, you notice a shift in the team. Not everyone has seen this before, some don’t agree with the splitting, others don’t agree with the proposed solution. The PO proposes to skip this item, but there aren’t many items that the teams thinks are ready. Finally we create a plan, but you feel the commitment ‘has been better’.
Way too much refinement.
We get situations where we refined some items a few weeks or months before. In Sprint Planning one of two things usually happens. One, people are unsure if these items are really necessary. An item that seemed pressing back then, but no one can tell why this was valuable. Or two, people have no idea what these items are about. Since we prefer talking over writing, a conversation we had a few months ago is hard to recollect. In the end, we have to do another refinement to get this clear. What a waste.
We need just in time collaboration on the Product Backlog to answer “do we understand what we are likely to do in the future?”, and “do we have just enough information to start working on it”. It is about finding a balance that works for you and your team, in order to prevent situations like this!
Who has to be there?
Some questions I have had in training and coaching are: Does the entire team have to be present in Refinement? Can the PO do it alone? Can the Dev Team do it by themselves? Can’t we do refinement in just 1-on-1’s? Do stakeholders and users have to be present? As often, it depends.
So what can we say. We know by now that it is about shared understanding of the value and intent of the items on the Product Backlog. If the PO puts something on the Product Backlog, he or she will likely be needed to elaborate on that item. For the Dev Team to understand, they may need to clarify with the PO and stakeholders. Since the Dev Team is accountable as a whole, it might be helpful to do at least some of the refinement together. If some clarification requires some more effort, sometimes it helps to let someone do that in a smaller setting. For filling in some details on how it could work, clarifying directly with users instead of with the PO might be more beneficial.
From my experience, in many teams the following two pitfalls happen with regards to involving whom at refinement:
- Too little use of stakeholders, users and experts
- Which might lead to assumptions and biases
- Too much refinement with just a small part or single persons from the team
- Which might lead to others feeling spoon-fed with precooked solutions
It is not about simply following the rules of refinement, it is about seeking collaboration to get the items on your Product Backlog ready. Involve who you need to, when you need to. Then inspect and adapt your refinement process to get better at it. It is about balance.
When do we do refinement?
In training usually someone asks why refinement is not an event? Good question.. One of the reasons is that it has no fixed time and place within the Sprint. How much Refinement and when to do it, really depends on the Dev Team, Product Owner and the maturity of the Product. For that reason, we rather describe it as an activity, that should take no more than 10% of the Dev Team time. If you want to fix that time in your agenda, go ahead.
The most prevalent scenarios I have seen working well are variation of the following:
- In 2-week Sprints, a big block in the second week as a more collaborative workshop. This could be half a day up to a full day. Teams often use the day that they would do Review, Retrospective and Planning in the first week. In this way there is time for deeper clarification, discussing with multiple stakeholders and looking at the system in action.
- 3 or 4 shorter blocks in a Sprint. For example blocks of 1 or 2 hours spread through the mid-part of the Sprint. This can help to bring focus to the sessions. There is time for discussion, but also time for questions that can be clarified between these refinement sessions.
- Daily blocks of 30 minutes together. It helps some teams to get in flow. There is little time for deep-dives, so we focus on the why and what of items. The PO as well as the Dev Team then clarify things in between the sessions.
No matter what timing you choose, make sure that everyone knows what the agenda is for that session. Refinement is more likely to go fluently when they are structured and prepared. Is it clear upfront which items are you going to discuss?
How
In the end team refinement should be a structured session where you collaborate to clarify and sharpen the Product Backlog. It can take many forms, like time-boxed discussions, collective sketching and drawing, Q&A sessions with subject matter experts or users, or discussing and creating key examples for validation. Proper facilitation helps to make these sessions engaging and outcome oriented.
Different structures from a brainstorm session to a good shift and share can be helpful as well as refinement practices like story mapping. It really depends on what type of item on the Backlog you are refining. Is this a new big and vague idea, or a small defect that popped up in production? Is it a relatively familiar type of update or is it some architectural innovation.
For me personally, key elements of any good refinement are:
- Time-boxing
- Clarity and focus on the agenda
- Open and curious conversations
- Well-structured process
- High level of engagement
The more people are actively doing something in refinement, instead of passively listening, the better the outcome usually is. At the last part of this article, I will share some more practices that might be helpful.
What works for your team, you have to figure out by doing. Don’t try to find that silver bullet for refinement, but inspect and adapt according to the context you are refining. There are several pitfalls though, that you can prevent. So maybe the better way to find your ‘how’, is by exploring how not to!
How not to
In my experience with refinement sessions the following (non-exhaustive) list of pitfalls or hindering patterns come across regularly. They are hindering when they do not help to achieve the goal of shared understanding on the Product Backlog items between the PO and DT. By offering a suggestion to focus on, I would like to help you break the pattern of non-engaging or non-effective refinement*.
* I am not offering silver bullet solutions, but suggestions.
Good Practices
In a complex environment, it always depends on what practices are helping in your context. User stories are not always a good idea, when you have no specific users to talk to. Collectively creating designs in drawings are not always helpful when you are dealing with mathematical problems.
Of course there is a multitude of practices that might help you with refinement. So let this be inspiration for you to try! There is excellent stuff written on each of these, use the power of google!
Hope this helps!
I am curious to what other pitfalls or good practices you have come across, and might be helpful to add to this list?