One of the things that I’ve noticed in my coaching of Scrum teams is how difficult it is to do effective backlog refinement. So, I thought I might release a series of short blog posts focused on backlog refinement, what it is and how it works. The first installment, “What is Backlog Refinement?” appears below. Enjoy!

What is Backlog Refinement?

Backlog Refinement is a completely new kind of workshop. Only a couple years ago, we never did anything like it before. It’s not taught in schools or universities and its not something that there are classes you can take to learn (yet).

At it’s simplest, backlog refinement is something that every Scrum team should consider doing one or two times a week for 60-90 minutes per workshop. During this workshop, we accomplish three goals:

• Estimate backlog items that have no estimate
• Correct estimates that appear to be considerably off target
• Discuss and divide backlog items into smaller component pieces (slicing).

Of the three goals, it is the third that is arguably the most important (though all of the three goals MUST be accomplished in each meeting). It is through this goal that analysis is accomplished in a Scrum project. Without it, we often find ourselves in long and unproductive Sprint Planning meetings and in Sprints that frequently fail to achieve the Sprint Goal because too many unexpected details are learned too late in the Sprint.

In a way, Backlog Refinement is much the same type of meeting as Sprint Planning. In both meetings, we discuss a backlog item and slice it into smaller pieces. In Backlog Refinement, we take large backlog items and separate them into smaller, functionally equivalent backlog items (that is, the combination of the functionality represented by the children of a backlog item accomplish the functionality required by the parent). In Sprint Planning, however, we take backlog items and separate them into very small tasks (usually limited to 16 hours in length).

This is where the similarity ends. In fact, the most important difference (and the one that, when misunderstood causes the most problems) is that Backlog Refinement DOES NOT SOLVE backlog items. In other words, during Backlog Refinement, we do not discuss HOW we are going to build something represented by a backlog item. We only speak of what the backlog item means functionally.

Here’s a simple example…

Let’s assume we have a backlog item that reads, “STORY 100: As the homeowner, I want a garden full of flowers in the front of my home so that the home looks beautiful and my neighbors are made envious.”

If this was Sprint Planning, we would take the backlog item mentioned above and divide it into tasks that get the job done:

1. Clear a patch of ground for the garden
2. Buy the flower bulbs.
3. Prepare the ground for the flowers.
4. Dig holes no more than 20cm apart and 40cm deep for the bulbs.
5. In each hole, place the bulb (top-up) in the hole along with some fertilizer and a little water.
6. Fill the hole and tap the ground down firmly.

You get the idea (I’m not a gardener). However, if this was Backlog Refinement, we would be creating functional slices of the backlog item:

• STORY 100.1: As the homeowner, I want the garden bordered by a series of white, low-lying flowers.
• STORY 100.2: As the homeowner, I want tall standing red tulips in the back of the garden, closest to the wall of my house.
• STORY 100.3: In front of the tulips, I want yellow flowers that are not going to grow taller than the red tulips.

Do you see the difference? In Sprint Planning, we SOLVE backlog items. In Backlog Refinement, we ELABORATE backlog items. There are more benefits, as well. Look at the first backlog item (the one marked STORY 100) and compare it to STORY 100.1, STORY 100.2, and STORY 100.3. Do you see that each of the “children” of STORY 100 are more descriptive and represent a smaller and simpler unit of work? They are smaller, because each describes only a piece of the garden, rather than STORY 100 that describes the entire garden. They are simpler because each discusses only one type of flower in addition to precisely where that flower should be placed relative to the edges of the garden. Smaller and simpler backlog items represent a smaller risk to Scrum teams that a significant mistake will occur or that unexpected effort will appear during the Sprint.

The problem caused in ineffective (or no) Backlog Refinement is that we can easily take what seems like a reasonable backlog item (“I want a garden full of flowers in the front of my home so that the home looks beautiful and my neighbors are made envious.”) and start solving it before we even understand the customer’s desires (a border of white flowers, red tulips closest to the home, yellow flowers in front of that). This will lead to customer dissatisfaction and significant rework. One of the goals of Agile Development is to eliminate as much rework as possible. This is one of the ways we can accomplish that goal.

And, of course, less rework means more time spent building valuable functionality.

In summary, Backlog Refinement is an important tool in the Scrum team’s toolkit. It is a 60-90 minute workshop held one or two times a week. Its main purpose is to prepare backlog items for Sprint Planning by reducing them into smaller and simpler items that describe WHAT the customer wants. In response to the lean development principle that recommends “deferring decisions until the last reasonable moment,” we do not attempt to determine HOW we will meet the customer’s desires until Sprint Planning (when there’s the smallest likelihood that the backlog item will be de-prioritized or removed from the project).

Be sure to read part two of this blog post!