What is Backlog Refinement in agile
Backlog Refinement is an important but poorly understood part of Scrum. It deals with understanding and refining scope so that it can be ready to be put into a sprint for a development team to turn into a product increment. Good backlog refinement involves a regular team discussion, plus informal ad hoc discussions. The output should be product backlog items, defined to an epic, story and/or task level. It is an iterative process that is done every sprint or more frequently, not once at the beginning of the project. I’ve worked with scrum for over 10 years, and I’ll share my experience and advice on backlog refinement here.
Background / Context
Scrum is an iterative agile development process. It involves a development team producing product increments each sprint, pulling items from a backlog into a two week sprint.
One of the common questions is exactly what sort of backlog items, and how they go from the backlog into the sprint.
The problem with backlog refinement
In scrum, a team has a Product Backlog, which is managed by the Product Owner. It contains the sum of the current thinking of what can be built for the product. The team pulls work from the backlog into a sprint, where it forms the sprint scope (i.e. sprint backlog). The team then has the goal of completing that work and producing a product increment. The problem is how work goes from being Product Backlog Items, to a Sprint Backlog.
The Scrum guide is vague and unclear on this matter. A lot of teams are unsure how to plan and prepare work to go into a sprint. A lot of teams either end up with no clear backlog to work with, or they spend too much time and have a giant complex backlog but delivering no software.
This article will provide some guidance on best practices on how to do backlog refinement.
So what’s the solution?
Regular backlog refinement
The main practice to solve this problem is to set up a regular Backlog Refinement meeting. This should happen initially on a cadence of once per sprint. After a few sprints, the team may want to discuss whether they want to increase or decrease the frequency of these meetings (e.g. twice per sprints, or once every two sprints).
The purpose of this meeting is:
- to prepare a number of product backlog items (PBIs) near the top of the backlog to a state where they are ready (or close to ready) to be pulled into the next sprint at the forthcoming sprint planning meeting
- to discuss items further down the product backlog, so the team has a better understanding of them
- to discuss and confirm the priority of the product backlog items, so the team has a shared understanding.
I have found that roughly halfway through the sprint is the best time for this meeting. If you have it at the end of the sprint, it doesn’t leave enough time for the team to find answers to questions they cannot answer in the meeting. If you have it at the beginning of the sprint, the landscape and context may have changed by the time the next sprint begins.
Ad hoc backlog refinement
It is important that the purpose of the Backlog Refinement meeting is to ensure that Backlog Refinement happens at least once per sprint, much like the Daily Scrum ensures the team is discussing and coordinating their work at least once per day. This does not of course mean that it is the only time that Backlog Refinement can happen! (Similar to how the Daily Scrum does not mean that the team cannot discuss and coordinate their work at times other than at the Daily Scrum).
Delivery Managers should encourage (and where appropriate, facilitate) backlog discussions at other times during the sprint.
Good story writing practices
If the team is doing Backlog Refinement properly, they should be refining backlog items such as User Stories (the most common type of PBI), to the point where they are in good shape and ready to pull into the next sprint.
Some basic story writing practices can go a long way to helping that happen.
While user story writing is its own topic (about which people have written books), here are some quick pointers.
- Give each story a quick summary title that describes what it is about – focus on the business problem or user action, rather than technical implementation
- Begin the user story description with “Story Normal Form” i.e. “As a (user), I want to (perform action), so that I can (achieve outcome).”, where appropriate
- Add one or more Acceptance Criteria for the story, in the form Given When Then (Given a certain condition, When some action occurs, Then a certain behaviour or result happens).
- Feel free to add some more notes or examples, but don’t put large amounts of content or documentation in a story – they are better off in Confluence (with links in Jira to that content). Jira is a tracking tool, not a knowledge repository.
Story estimation
A team may want to also estimate their product backlog items in the Backlog Refinement meeting. They could do this by using Planning Poker or some other method. (I talked about alternatives to Planning Poker here, if you are interested). They may also want to leave the estimation for later in the sprint, even as late as the Sprint Planning meeting.
The advantage of leaving the estimation until later is that the team has more time to understand and further refine the backlog items, which will increase the accuracy of the estimates. The disadvantage is that the team may struggle to come up with the estimates in a sprint planning meeting. There is also no further time if there are unanswered questions at sprint planning to resolve those questions before the items get estimated and pulled into the sprint.
Alternatives / advanced topics
Story mapping
Story mapping is a method for constructing “flows” or “user journeys” through a system. It can enable a team to quickly identify and construct backlog items that are related together in terms of the actions a user would take.
It is an excellent collaborative activity and works very well for pulling together a coherent set of related stories, rather than a random laundry list or grab-bag of tasks.
If you want to know more, I would recommend the book “User Story Mapping” by Jeff Patton.
Impact Mapping
Impact Mapping is a variation on Story Mapping, created by Agile testing author Gojko Adzic. This system focuses on the “who” and “why”, i.e. who is being potentially impacted by the product and why, rather than the “what” and “how” (i.e implementation). You start by identifying the Goals or Effects you are trying to achieve (“why”), then consider the actors who will be impacted (“who”), then identify the actual impacts you are looking to achieve (“how”), then finally the deliverables required to achieve those impacts (“what’).
This is a good system that encourages breadth-first product thinking, rather than piecemeal iterative backlogs that are just laundry lists of implementation ideas.
There is a good introduction article to Impact Mapping here, or I would also recommend the Impact Mapping book itself if you want to learn more.
Definition of Ready
A team may want to implement a “Definition of Ready” – similar to a Definition of Done, but this describes the minimum criteria for a story to be considered ready to move into a sprint. (Check my article on Definition of Done if you are unsure what that is or how to use it).
For example, the Definition of Ready might specify that PBIs need a description, two or more acceptance criteria, links to a user interface design, and example use cases / test data.
This can be good for enforcing teams to get a minimum standard of understanding around stories, and can help teams that are struggling with incomplete or barely defined stories. However, the team should take care that it does not become excessively strict and a Waterfall-style “phase gate” (which could become an antipattern, see below).
Dangers / Antipatterns
Design sprints / dual track sprints
One of the dangers or anti-patterns of backlog refinement is to split work into “design sprints”, when stories are analysed and written, and “dev sprints”, when they are built. To make sure people are not waiting, this often becomes “dual-track sprints”, where half of the team are working on analysing work for the next sprint, and the other half are developing work that was designed in the previous sprint.
While it can make sense to have some people in the team looking more ahead at upcoming work and others more in the trenches, it is important to remember that Scrum is a team-based approach, and the team should be working together to complete a product increment at the end of each sprint. Splitting the work in two can quickly lead to handovers, blocked work and mini-Waterfalls.
Backlog as Laundry List
Another antipattern has recently become common due to the prevalence of tools like Jira. That is the “Laundry List” backlog. What teams need is a coherent product roadmap with a variety of product backlog items at different levels of fidelity, all linked by business themes or problems. Instead, they often just get a big list of 200 random Jira tickets, with no particular theme or thread. Teams are just expected to mechanically pull the top 10 or whatever tickets off the top of the backlog each sprint, and ask no further questions.
This is a terrible practice and a recipe for a failed product. Techniques such as MoSCoW analysis, Story Mapping and Impact Mapping were specifically designed to solve these problems and help teams understand the actual business and user thinking and problems that they are trying to solve. Teams should work iteratively and collaboratively with product managers to understand:
- what is our business bottlenecks or constraints (read up on Theory of Constraints if you aren’t familiar with this concept)
- what are our customers looking for that the market doesn’t currently supply?
- what are the exciters and delighters (from the Kano Quadrant theory) that we haven’t found and can investigate?
- what are the must haves and should haves that we need to make sure we haven’t forgotten?
Backlog Refinement when done properly, with breadth-first product thinking, can help answer all of these questions.
Implementation defined rather than problems
It is important to remember that user stories (or other product backlog items) are problem statements, not solution statements. They describe a business or customer problem to be solved. The purpose of backlog refinement is not to choose and define and commit to an implementation. One of the principles of Lean Software Development is “Decide as Late as Possible”. The implementation is not part of the problem definition, and should be decided as the work is begun and explored, not ahead of time. Excessive details around implementation in a user story are a red flag that the team is making too many up-front assumptions about implementation.
Nothing but Jira or similar tools
Another thing to look out for is that Backlog Refinement becomes just a placeholder for the team to watch the product owner drag tickets around in Jira, or some other similar agile software development tool. Remember, this is supposed to be a meeting, and a collaborative discussion. It is not just an excuse to update the status and order of tickets!
The product owner should be using this opportunity to discuss their latest thoughts on the product vision and roadmap. The team should be using this opportunity to discuss their thoughts on how the product is going and what directions it could take. The scrum-master should take this opportunity to help coach the team on how to construct and maintain a product roadmap.
Updating tickets is something that can be done any time. While story writing is important, the context and conversation around those user stories is what’s really important. Remember the old definition of a user story: “A placeholder for a conversation”.
Conclusion
Backlog Refinement is an important part of any agile methodology. The approach described here is a simple, lightweight and effective one: the team meets at least once formally (but probably more informally) to discuss and gain a shared understanding of the items in their backlog. The outcome should be a set of stories
