The Challenge of Backlog Refinement
And how to use it more effectively
It seems to be a wide-spread idea that doing Agile means that there is no need for planning or preparation. Planning is seen as ‘waterfall’ and the feeling seems to be that the uncertainty inherent in a complex environment means it is a waste of time to even try. People are genuinely convinced that everything will become apparent as Sprints progress.
With this frame of mind it is not surprising Backlog Refinement ends up as an afterthought with a very limited role.
However, I think Backlog Refinement is an essential parts of Scrum, as the preparation it catalyses is often critical to running successful Sprints. In software development, preparing the work properly is how we manage the information that gives our work its name: Information Technology. Developers, certainly in a Scrum Team, are no longer production workers responsible for writing lines of code, but information managers, experts in finding ways to organise and manage information.
With these thoughts in mind, it becomes clear that without some kind of rough backlog to allow a team to set priorities and oversee what they are getting themselves into, running Sprints is like headless chickens running around in a yard — your velocity may be very high but you have no idea where you are going. The chance you will end up smashing your face against a wall is very high.
In practice, I find that Backlog Refinement is frequently a major challenge. For me, it has always been one of the major hurdles for implementing Scrum, symbolic of the negative things people see in Scrum: too many meetings, too much work leaving too little time for productivity, too hard, unclear results.
So how can we improve this situation? Over the years, working with different kinds of teams and trying various approaches, I have collected the following insights.
It has different goals
Ever notice that often those very long discussions in Backlog Refinement have to do with different perspectives? The Product Owner is thinking about priorities, one developer is thinking business value, another is thinking of the context within which something will be developed, another one sees all the risks, the last one can’t wait to dive in with the newest tech.
Basically, people are mixing different goals, so the conversation ends up going in circles all over the place.
These are the different goals which I have identified for refinement together with various teams, in no particular order:
Why are we building something?
What are we going to build (rough idea — enough for alignment)?
How much effort will it take?
With this in mind, it is obvious that splitting Backlog Refinement into different parts, each part focusing on one of the goals is a good idea. For example, I’ve had teams where Backlog Refinement evolved into 4 distinct activities:
plenary brainstorm by the team, to create a common understanding and gather collective insights,
story preparation, in which missing information is collected and assumptions are validated,
estimation,
prioritisation and rough planning.
It is important to realise that these goals can be approached at different levels of detail and not all of them are always required. For example, initially the Product Owner may only want a rough indication of the effort needed to build something, just to be able to decide whether it is worthwhile to refine further. He may only want to dive into the details after that, to improve the final estimate.
Clearly, a good collaboration between the Product Owner, who decides the goal of each session, and the Scrum Master, who chooses the best way to facilitate the event to achieve the given goal., is important for successful refinement.
It Doesn’t Have to be a Meeting
The Scrum Guide talks about “events”. This is not an attempt at being elitist or at making things unnecessarily vague. I think that the choice of the word “event” has the purpose of leaving the implementation open, allowing us to channel the empiric character of Scrum towards evolving the event into a method that fits our particular situation. A meeting may seem like the obvious first choice, but gradual improvements will often see that change.
Considering the three separate activities I described above, I tend to replace meetings with the following:
Collecting insights — I’ll usually use a 1–2–4-all liberating structure for this one, sometimes followed by a min specs to brainstorm what the must-haves are,
Story preparation — entrusting user stories to members of the team for research, individually or in pairs, is very efficient. Of course, only if a user story is actually missing information. I’ll leave people to figure out the details of the user story, using INVEST as guidelines for writing a good user story and, if necessary, SPIDR to effectively decompose them into smaller stories. The Product Owner usually determines a time-cap.
Estimation — After reading each user story the team plays their poker cards silently and only discusses the user story shortly (2–3 minutes) if the estimates vary. If no consensus is reached within the timebox we move the user story back to step one.
Prioritisation — I like to use something akin to a timeline retrospective. I will draw a timeline on a whiteboard and use post-its to add the new user stories. Work which already has a place I will summarise in one post-it, for example in epics.
Nothing helps more to get a grip of a global planning than being able to visualise it together and being able to easily move things around.
It stands above the Sprint level
Too often I see Backlog Refinement as a last-minute scramble to prepare work for the upcoming Sprint. “We have to estimate these user stories so we have enough work for the Sprint!”. And if the estimates turn out to be lower than expected, the unreal situation whereby there is no joy, but instead the frustration and stress of finding other work on time to start the next Sprint!
Changing the focus of the Backlog Refinement from the upcoming Sprint to a higher level encompassing the foreseeable future allows the development of an extensive backlog of work waiting to be refined.
If we then use Backlog Refinement as an iterative activity, in which we gradually sharpen the level of detail of all that work, it is easy to always have a ready buffer of work for a team. Furthermore, it also helps the team to keep sight of the overlying context of the individual chunks of work.
To help determine a rhythm for this iterative process I find the rule of having roughly 3 Sprints of work in the backlog ready to be picked up surprisingly valuable. It feels like a rather artificial rule, but it is effective, as it creates a very good balance between having a work buffer and not investing too much time on work that may have to be reviewed due to changing requirements and new insights.
It’s an investment
It is important to realise that Backlog Refinement does not just work out of the box. It is a complex event that requires investment at two levels.
First of all, at the temporal level, it involves making an investment that only bears fruit later, during a Sprint, when the work gets picked up. This feedback delay often makes it difficult to improve Backlog Refinement.
Second, at the competency level, it involves investing in various skills that are not necessarily the typical skills developers get hired for. Teams, therefore, need room to develop these skills.
It is therefore very important as a Scrum Master to approach the improvement of the Backlog Refinement with extra attention, simply because, due to the temporal factor, the effect of Backlog Refinement may be obscured.
For example, when discussing a user story that wasn’t finished in the Sprint, I often find that teams will focus on events during the Sprint Planning and the Sprint itself. The fact that the user story in question might not have been properly prepared in the Backlog Refinement is often something I need to point out before the team becomes aware of it.
Also, patience! Scrum makes it possible to fix problems very effectively. Often, a problem arising in a Sprint is fixed in the following Sprint. But with Backlog Refinement, everyone, and especially stakeholders, need to be made aware that fixes take longer before they have the desired effect.
Estimation is perhaps the best example of this. We all know estimating is really, really hard, and something that takes practice and experience to develop. Yet I often find that there is little patience for inaccurate estimation, especially in companies still very much attached to their fixed scope & time approach.
It’s a planning tool
The Scrum Guide says “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog”. The way I interpret this is that the main focus of the Backlog Refinement is on refining user stories to clarify their value, which in turn allows work to be prioritised better.
Figuring out how to build something — the implementation — is something that should be worked out in the Sprint Planning and the Sprint itself. This is very important because it leaves the implementation to the last possible moment — right at the beginning of the Sprint — the most efficient moment to figure it out.
Of course, to give accurate estimates, a Scrum Team needs to have some general idea of the implementation. Like most things Agile, it’s a grey area. But it helps to realise that the implementation should only be discussed in so far as it helps to improve alignment.
I find that realising that the Backlog Refinement is about alignment takes a lot of pressure off the event, helping to make it a more relaxed, fast-moving activity. The team no longer feel they have to figure everything out perfectly. Gradually, as their experience increases, the team begins to see the Backlog Refinement as a continuous routine of attention to the Backlog, with the event itself being only the highlight of the process, where everything comes together.
With these insights, I have seen Backlog Refinement grow in my teams to a shared and valued part of the Scrum Process. It has helped my teams to really understand the event and wield it as an effective tool, to the extent that it becomes second nature.
But it has even further-reaching results. I have seen it bring developers closer to the Product Owner, resulting in better cooperation to manage the Backlog. In one team, because they could suddenly choose user stories from a large buffer, the use of Sprint Goals was quite naturally adopted.
I think my favourite is seeing the Product Owner describing some general requirements after the Daily Scrum and getting estimates in minutes. That’s the kind of agility we are all aiming at!