How To: Backlog Refinement

Let’s get some terminology out of the way before I get into describing what Product Backlog Refinement is, and how to go about doing it.

It’s officially called Product Backlog Refinement.  It’s not Story Refinement, Story Time, Story Telling Time, Grooming, Elaboration, Estimation, Pruning, Priority Time, or any other creative term your company is currently calling it.  It is currently, officially called Product Backlog Refinement.  That being said, from here on out, on this page, I’m going to call it Refinement (that should give you an idea of just how much I care which words are used to describe complex concepts).

I assume there are many different formats to doing Refinement, because it’s not an official Scrum Event.  Refinement may possibly become an official event in the future, but as it stands now, it’s an ongoing activity that takes place in many different forms, throughout the Sprint, and not on a predetermined schedule defined by the Scrum Guide, or any other governing body or document.  This is why I advise teams to try different formats and cadences for Refinement, figure out what works best for them, and then do that.

Before we get to describing my favorite two formats, let’s talk about cadences for Refinement.  Your team’s cadence will be based on many different factors.  How organized are you?  How strict are you with schedules?  How much time are you going to allow for creativity?  How messed up is your Product Backlog?  How big is your team?  How familiar is your team with the technologies they are using?  How much time is your Product Owner spending on ordering the Product Backlog, and refining PBI’s on their own?  Like I said, lots of factors.

Refinement cadences aren’t just about how often you refine, they’re about how long you spend refining once you get the people together.  For new teams, I generally tell them not to set a very strict timebox for their first few Refinement sessions.  I tell them to see how much they can get done in a hour.  If they have to go over by 15 minutes, no big deal.  Their goal is to find out how much refining they can get done in a certain amount of time.  More mature teams should set a timebox, and stick to it.  Their time is valuable, and it shouldn’t be wasted.  Discuss, in Retrospectives, whether the Refinement sessions need to be more frequent, longer, shorter, etc. and experiment with your decisions.

Once the team has the length of Refinement sessions set, start working on how many times to hold Refinement during each Sprint.  Some teams believe it’s best to do the same number of Refinement sessions for every Sprint.  Your team may need a variable number of sessions.  There is no one-size-fits-all here.  Do what’s right for your team.  My suggestion, several short Refinement sessions per Sprint is much easier to digest than one REALLY long session in the middle, or at the end, of the Sprint.

Whole Team Refinement
Whole Team Refinement is just that, the whole Scrum Team involved in refining Product Backlog Items.  The entire team gathers together and reviews each PBI at the top of the Product Backlog.  Your specific team’s goals are going to differ from other teams, but in general you should be trying to reduce the size of PBI’s so they can be confidently completed in a single Sprint; estimate each PBI refined; reduce the ambiguity or vagueness.  How you go about achieving this is completely up to the team.  Try out some different styles and see what the team prefers.

3 Amigos
The 3 Amigos, in Refinement, refers to team members representing Business, Development and Testing getting together to refine PBI’s.  The Agile Alliance has a great article on the 3 Amigos concept, check it out and then come back here.  Now that you know a little about 3 Amigos, imagine this trio sitting in a room talking about the top items on the Product Backlog.  You lose a little perspective, right?  The rest of the team is working away in the Team Room, and the 3 Amigos are off talking about the PBI’s on their own.  Not a good idea, right?

Well, it has it’s advantages.  The 3 Amigos approach allows the items to get somewhat refined quickly, without interrupting the entire team.  You also get some of your best people looking at these items first.  I stress ‘first,’ because the entire team should review the items together, or on their own, before the Sprint Planning event that these items are offered up by the Product Owner.  After all, it is each Development Team Member’s responsibility to be familiar with the PBI’s that are coming up soon.

My Personal Advice
I suggest that new teams try out a pattern of using both Whole Team and 3 Amigos Refinement formats.  I suggest new teams use 3 Amigos after the first sprint begins, then follow it up a couple days later with Whole Team, and then towards the end of the sprint, try 3 Amigos again.  Talk about your experiences with the state of the Product Backlog, and in Refinement sessions, in the Sprint Retrospective, and find out what the team prefers.  If they can’t decide, keep alternating what format to use in each Refinement session.  If the team eventually prefers one format over another, use that one more often.  If not, just keep alternating.