Why Backlog Refinement Should Be A First Class Citizen

Backlog Refinement has been gaining momentum as a best practice in Scrum. I think it’s so important that I champion it to be a standard event, on par with Sprint Planning, Sprint Retrospectives, and Standups. (If you agree you should go to the Scrum Guide’s site and vote it up). I believe in order to be highly effective, the whole team should participate in this critical activity.

With the introduction of the Backlog Refinement event, you can address many challenges teams face. Most importantly, effective Sprint Planning, which will lead to a more stable and predictable delivery cadence. Let me share a story from a developer I know:

When I was a Director of Development, I would often need to lean on others as technical experts when trying to work through problems and solutions. We had a great lead developer on our team who I would collaborate with often named *Joe. I would grab Joe and head to a nearby whiteboard and sketch out my ideas, talking fast and drawing furiously. Meanwhile, Joe would have his hand on his chin and nod along in deep thought, taking it all in. I would get to the end and ask him what he thought, wanting to make a quick decision and move forward. However, Joe would say, “Let me think about it.” I would impatiently but respectfully say, “OK” and we would take a break. Later that day or the next, Joe would grab me and walk me back to the whiteboard. That’s how I knew he was ready to share his thoughts and work on a solution.

Do you know any developers like Joe? Individuals who have to wrap their head around the whole problem and look at it from all angles before they are ready to move forward? Most good developers are like that; that’s what makes them good. They think about all the things that could wrong so that they come up with a good, robust design.

So let’s think about what is happening to these poor developers when we conduct Sprint Planning without team-based Backlog Refinement prior to the meeting:

The developers walk into the Sprint Planning room without any idea of what they will be committing to that day. The ScrumMaster kicks off the meeting, explaining that in a second the Product Owner will share with the team the top items on the backlog. Then the team will have a few hours to commit to the next 2 weeks of their life. Surprise!

Developer love surprises, right? I don’t know about you, but I wouldn’t say developers embrace spontaneity. Isn’t that a cruel trick to play on them? Why don’t we spend a few moments ahead of time preparing the developers for what’s to come? That’s where Backlog Refinement comes in.

Backlog Refinement is an activity we recommend teams do every Sprint as a whole team with the Product Owner. There is no set timebox, however, I recommend about 1hr per week of your Sprint. I typically like to schedule this in the middle of the Sprint, right after the Daily Scrum for about two hours. So if we start our Sprints on Wednesdays and every other week is Sprint Planning, then the Wednesdays in between would be Backlog Refinement mornings.

The top priority of Backlog Refinement is to make sure we have enough work ready for the next Sprint. I like to set a goal to have 2-3 Sprints worth of Ready stories at all times. This ensures the team always has enough items to pull. There are two major elements to being ready:

1. Do we understand the work? – Have we reviewed Acceptance Criteria? Do we have any major open questions? Asking these questions days before Sprint Planning will allow the Product Owner to get all the answers.
2. Is the team going to be ready to start the work? – Do we have enough of a design strategy figured out to task it in Sprint Planning? Do we have any outside dependencies that need to be resolved first (i.e. access, DB, API, etc.)? Do we have the knowledge or do we need to get up to speed first?

The second focus is to partner with the Product Owner to break work down. Often, user stories start as Epics, and it is the team’s job to partner with the Product Owner to figure out the best way to break the functionality down into chunks that can lead to a Potentially Shippable Product Increment.

As we do this, we will need to resize the items, which leads to the third focus area: estimating. Most user story level estimating is done in Backlog Refinement, not Sprint Planning. Again, the goal is to get full team input on the size and to leverage everyone’s perspective. The Product Owner needs these estimates in order to properly prioritize the backlog prior to Sprint Planning. The team also often uses this time to ask the Product Owners questions to clarify scope and connections to other tasks or stories.

Some teams try and make this meeting more “efficient” by just sending the lead developer to represent the team. However, this leads to only one person understanding and ready to start the work while the other developers are still surprised when they walk into Sprint Planning. Who do you think they will rely on to create the plan for them? Will this be a shared plan and shared commitment or the lead developer’s plan? Would it be fair to hold the whole team accountable if it isn’t their plan?

If the team spends a few hours per Sprint together doing Backlog Refinement, then this will allow Sprint Planning to go smoother and faster. It will also limit the number of surprises that surface during the Sprint. Which, in turn, will lead to more predictable velocity and less rework of features. If we actually understand the scope of what we need to do before we even start, we might get a better product.

*Joe is not this person’s real name