Don’t Forget Backlog Refinement

Backlog refinement is where the Team and Product Owner collaborate to ensure items in the product backlog are:

  • ready and understood

  • prioritised

  • estimated

Regular Backlog Refinement provides many benefits for teams and organisations but it is something we continually see underused or, even more damagingly, completely ignored.

Some negative Backlog Refinement scenarios we regularly see:

Teams ignore Backlog Refinement and rely completely on Sprint Planning.
In this scenario it is often the Team's first sight of the backlog item(s). The Team ask questions that cannot be answered but the sprint is due to start! There is "no time" (or no desire) for the Product Owner to take the item away and get the questions answered.

Developers get pressured into putting an estimate onto the item and work out what to do with limited information and time. This pattern continues, estimations are continually poor and the team regularly misses their goals. They become demoralised and feel pressured. Sprint Planning takes ages too.

Backlog Refinement is held near the end of one sprint to 'ensure' the backlog is ready for the next sprint.
One out of the Agile textbook but in the real world we often see this pattern still putting pressure on teams. When the Team ask questions the Product Owner still has only limited time to take the item away so the feedback loop between the Team and stakeholders remains long. It also encourages sprint-by-sprint planning and while this is fine with just-in-time advocates it is rarely practical, particularly in larger organisations.

Separate or ad-hoc meetings
One of the advantages of utilising and respecting the Agile events is that they protect the team from interruptions and reduce meetings. (There are no "quick questions" when someone is deep in work, but that's for another post).

We often see the scenarios below, either done without backlog refinement or in addition to backlog refinement. These practices serve only to add to the number of meetings and provide regular interruptions for the Team. Some examples include:

"It [backlog refinement] can get boring for some people when it gets technical so the 'techie people' have a separate meeting". This scenario can often be the result of wider issues such as a lack of understanding about delivery of value and breaking down backlog items such as user stories. It also contributes to a negative 'them' and 'us' culture and is generally divisive.

Risk and issue management meetings with the team.

Lots of short ad-hoc meetings with developers. Businesses and Teams not investing in quality planning and not realising Agile's in-built ability to reduce risk often fall into this pattern.

Why use Backlog Refinement?
In short, Backlog Refinement presents a great opportunity for collaboration and to create a shared understanding of:

  • what the Product will, and won't, do

  • the effort it will take to implement it

  • the order in which you’ll do it

But there a number of other advantages of Backlog Refinement that are often overlooked.

Used in conjunction with the Agile events - Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective - Backlog Refining can help the team maintain a steady, sustainable rhythm of releasing. For example:

Agile cadence

Acheiving cadene through regular backlog refinement

This type of cadence:

  • protects the team. Unplanned interruptions are kept to a minimum because the events and backlog refining are pre-planned and time-boxed. The team know when they're happening and for how long so can factor this into their velocity.

  • improves the feedback loop between the team and stakeholders because they have more time to ask questions and develop a shared understanding.

  • reduces unplanned surprises at sprint planning. The event becomes becomes more effective and efficient because the team have has early visibility.

  • contributes to a more refined backlog. Teams can plan further out and if the team have underestimated or find them selves with additional capacity there is more likely to be 'ready' and understood items in the backlog that can be brought into the sprint.

It's easy to forget about refining your backlog and see it as just another meeting. But it really is a powerful tool to help teams build a sustainable rhythm of delivery.

Previous
Previous

A Seasonal Introduction to Kanban 🎄