Refinement
According to the Scrum Guide “Product Backlog refinement is the act of breaking down and further defining Product Backlog items (PBIs) into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.” It also tells us that through Sprint Planning, when the developers are deciding what can be done during the Sprint “the Scrum Team may refine Product Backlog items… which increases understanding and confidence.” Recently, during one of our weekly Agile Coaching Circle sessions, our team discussed refinement and I’d like to share some of the highlights with you!
Is Refinement a Scrum event?
The answer is….kind of. While the Scrum Guide doesn’t explicitly include Refinement in its list of events, it does acknowledge that Refinement should happen on an ongoing basis. For teams we coach, especially teams who are just starting out, we encourage Refinement as a set event in their sprint, representing approximately 10% of their total sprint time. This can be broken out into multiple sessions as the team sees fit. Teams ideally want to have 2–3 Sprints worth of refined PBIs in their backlog at any given time. If a team sees that they are running low on refined work, it may be necessary to schedule additional refinement sessions within their sprint above and beyond this 10%.
What happens in Refinement?
During the Refinement session, the Product Owner presents the PBIs to the delivery team- WHAT is being asked for, WHO is impacted by the work, and WHY it is important and valuable to the end users. While the development team may start to think about HOW they will do the work, the discussion really focuses on the WHAT, WHO and WHY first, and they generally do not get into tasking at this point (we’ll come back to this later). Refinement also allows for some negotiation. While the PO may have a pre-conceived notion of what will be required, the developers may actually propose a different way of delivering the same value at a lower “cost” or effort. Ideally the result of this discussion and negotiation is a re-prioritized backlog where the PO may move up some items that the developers have identified as “quick wins”.
Some teams choose to create estimates of the work during the refinement session, and this extra step creates further opportunity for alignment and discussion among the team, as well as assisting the team plan how much work they can bring into upcoming Sprints. The numbers or sizes the team comes up with during this estimation activity is less important than the discussion that it elicits, especially when it highlights major differences in the efforts estimated by individual developers. We also expect that estimates are weighted differently from team to team, and are simply a tool that the team uses to better understand the complexity and effort involved in the work.
Why is Refinement important?
Refinement gives the whole team an opportunity to better understand the work that’s being asked for, creates an opportunity for discussion, alignment and negotiation as described above. It also sets the team up for more effective planning sessions, because the team has had a chance to review and align on the PBIs prior to committing to delivering them. They also have the chance to ask clarifying questions, or to indicate if a PBI isn’t really yet ready for consumption by the team.
Refinement & Planning?
As noted above, for some of our CoE coaches, Refinement is treated as it’s own event, separate from the four hours of planning that the team sets aside to start out their 2 week Sprint. This clear delineation between the two events ensures that the developers do not jump ahead to tasking- the HOW(which happens in the Sprint Planning session) and focus on the WHAT and WHY of the work. We’ll talk more about the ins and outs of the Sprint Planning session in an upcoming article, so stay tuned!
For other CoE coaches, refinement is actually imbedded within Planning and teams may start to engage in tasking activities within their refinement sessions. This allows the team to start thinking about HOW the work will be delivered to better understand the WHAT and the WHY. The time in refinement can then be deducted from the time set aside for Planning. This would technically reduce the hours of meetings the team would need to attend.
Personally, I prefer the first approach, but I can see how teams may wish to experiment with the second approach as they grow together and become more adept at their processes and collaboration.
Last thoughts on Refinement
Some teams may struggle with the quality and efficacy of their Planning sessions, and this is often a symptom of a lack of effective upstream refinement. Refinement is very important to ensure that the team fully understands the work outlined in their Product Backlog and have the opportunity to challenge and negotiate the work being asked of them before they commit to that work in their Sprint. It’s also an opportunity for the team to collaborate and seek alignment. Good Refinement leads to good Planning that leads to effective and efficient sprints, ultimately resulting in valuable solutions for our customers.
