Two steps to backlog refinement
Ordered backlog is a very powerful tool for managing work. However it is not a passive approach. There needs to be a strong focus on ensuring that the backlog is as effective as it can be.
Current thinking changes, priorities shift and the backlog must change to match.
If it does not, there is a mismatch leading to two sources of the truth. There is a real business need and this can be separated from the priorities captured in the backlog. If these misalign, people will use their private sources of data and the value of the backlog drops sharply.
There is often a perception that “Agile teams do not plan”. The reality is that Agile teams plan differently from project teams. Projects tend to rely on specific planners and concentrate planning at the start of the project. Agile development has a more continuous process involving the whole team. This is one of the areas where teams need to invest. Managing and maintaining the backlog is known as “backlog refinement”. This does not happen by chance and needs the investment of substantial time and effort.
Backlog refinement is a key process. Curiously, the Scrum Guide does not identify it as an “event”, which can lead to teams starting with Scrum underplaying its importance. Scrum refers to this as “an ongoing activity to add details, such as a description, order, and size” but perhaps underplays its criticality.
Effective, ongoing backlog refinement is
one of the key factors in smooth running
of a team’s work.
Backlog refinement covers two key areas, which are related but distinct.
Reprioritisation
It is critical that the backlog ordering matches the current business prioritisation. However, that doesn’t happen by chance. There is constant work needed to capture and agree the priority and reflect it in the backlog. Backlog ordering may be affected by learnings within the team. Or it may change due to external pressure and learnings from customers.
- The backlog may need to be reordered because a new feature has been proposed.
- Or because a defect has been found requiring rework.
- Perhaps some code needs refactoring because of technical debt.
- Or the work can better be done in a different order
Reprioritisation requires open communication around the organization. The backlog needs to be visible. There needs to be an understanding that the developers will be working to that ordering. And there needs to be a process to allow people to question this ordering by reviewing the priorities. Finally the consequences of change need to be published in some form, at least as a high level roadmap.
Decomposition
The other main activity in backlog refinement is breaking down large work items to smaller ones.
When items are proposed, and are far down the backlog, they may be poorly understood and often large in size. However, these items cannot directly be worked on.
There is little value in saying the top item is most important if it cannot actually be started. A process is therefore needed to take the larger items further down the list, and refine them as they move up the list. This is often called “splitting” as the items are broken down into smaller items. As a result the items at the top at any time are “rightsized” for development. They are also clearly enough defined to start work according to a “Definition of Ready” and can be started as needed.
If the teams do not invest enough in backlog refinement, the top items will not be not well understood. The team then end up working on items lower on the list, so breaking the common understanding of priority.
There are many techniques for decomposition, which include:
- Breaking out research activities or “Spikes”
- Identifying specific paths through the functionality
- Separating different interfaces or tools supported
- Splitting into items which support different data
- Implementing different rules independently
Good practices
As a leader, you should ensure that your teams implement regular and effective backlog refinement. It is probably the most critical planning activity. A common error is to leave this to Sprint Planning, while a robust refinement will make Sprint Planning a far simpler event.
You should make sure that the backlog is available and visible so that any changes are clearly understood and communicated.
Remind the team that the backlog is an asset, not a threat. Remember to think of backlog as fuel for the fire. Throwing on a log which is too big is likely to set back the fire, or even smother it. Backlog refinement is about splitting the logs into burnable pieces – batons or kindling. Having large logs for future fuel is fine. Just as long as they are ready by the point that you burn them.
Leave a Reply