How to refine your backlog more efficiently - through disciplined preparation

As I described in my previous blog, most teams do not do enough backlog refinement. This is due to team internal resistance in many cases: teams may feel that the backlog refinement practice is a waste of time. They find defining work items before starting so inefficient that it is easier to accept the waste and just work and find out the hard way what needs to be done.

What to do if your team is reluctant to refine the backlog

You can address team resistance in a few different ways:

1. Focus your refinement effort on non-routine tasks
2. Consider if whole team participation is beneficial, or should you refine with a sub-group
3. Organize item preparation better

Routine tasks do not usually benefit from refinement. These tasks already have unwritten "acceptance criteria" that the team already knows well. Skip these items – unless someone notices that a task that looks like routine is, in fact, not.

While I support full team participation in backlog refinement sessions, this may not make sense if the team is extensive. If you have a five-member team, go for "everyone participates". With ten or more members in the team, consider refining with selected participants only. While information sharing is a key benefit of refinement, you can also achieve it in other, more efficient ways.

This blog will now look in detail at the third point of the list – better preparation.

Develop a disciplined preparation approach for backlog refinement

What follows is a process of adding more disciplined preparation to your backlog refinement. See my previous blog if you want to look at the entire refinement process.

Preparations before the session: 

1. The Product Owner chooses the items that require refinement.
2. The Product Owner finds a suitable person from the development team who can further prepare the items, OR the team self-organizes to find the best person to take the preparation responsibility.
3. The selected team members prepare the items.
4. The Product Owner sends out an email to the refinement session participants to remind them to get familiar with the prepared items before the session.
5. The refinement participants study the prepared items and log down potential questions or comments, and pre-consider the effort level involved.

During the session:

1. Choose a refinement session secretary who keeps a memo.
2. The Product Owner states which item is handled first.
3. The team has an opportunity to comment or ask questions about the item. If no comments or questions are forthcoming at this point, you can proceed directly to the next step without further discussion.
4. Team members estimate the effort of the item with planning poker.
5. If the results of planning poker are within reasonable variance, the effort is logged, and the team progresses to the next item on the list.
6. If the results of planning poker show considerable variance in effort estimates, the team discusses the factors that led to differing effort estimates. The discussion results are documented in the ticket.
7. The team re-estimates the task until it can move to the next item on the list.

Things teams must agree on

As you can see, this process is more complex and challenging than the simple approach described in the previous blog. Don't worry, though: the process is not as difficult in practice as it may sound. Still, several steps require agreement, and overall, the process requires some discipline.

Things that teams need to agree on include:

• How can the Product Owner request a team member to prepare an item? 
• How much time should be spent on refinement preparation tasks?
• How do the refinement preparation tasks compare to the rest of the items in the standard workflow (i.e., agreed and committed sprint content)?

There's a twist to this: agile team members should not be assigned work. They should volunteer for the work. So, does the team allow the Product Owner to ask a team member directly for refinement preparation effort? 

Another alternative to the PO assigning the preparation task is for the PO to ask for the team to assign it. In this case, the team must have a process to self-manage which team member has the required expertise and capacity for the preparation. This is slightly more difficult than the PO directly asking someone to do the preparation, but it is more in line with Agile principles. The team should experiment which one of these two approaches works best for them.

What to do if planned and assigned preparation work fails?

If preparation without a work ticket repeatedly fails due to other work commitments, creating "refinement tickets" to the sprint backlog is an option. I don’t really like this approach because it resembles a "specification waterfall". Still, it is a valid approach to experiment.

How much time is enough?

The team should also discuss and agree on the scope of preparation. How much time should be spent on it?

Around 20-30 minutes often gives enough preparation time for most items as a starting point. Spending 20-30 minutes per item is surely possible to find even while working on the current sprint committed outcomes. 

What does preparation really mean?

The person doing the preparation should consider and document the following:

• What is the "why" of the backlog item – why should the team do it?
• The end-user benefit of the item (if possible).
• Description of the backlog item.
• Acceptance criteria (list 3-8 acceptance criteria).
• If the backlog item needs to be split into smaller items, a recommendation on how to do it.
• What the team should not implement in this backlog item.

It is all about discipline

This way of preparing for backlog refinement has a couple of extra deadline-driven steps that require the team to have a fair bit of discipline.

• The team must do the preparation work within a couple of days. 
• The team members participating in the refinement must read and consider the items before the refinement session.

A good preparation schedule helps develop the discipline

I recommend that teams set up a strict routine timeline that helps develop and maintain the required discipline. For example:

• Backlog refinement is done at the same time every Tuesday morning at 10 am.
• The prepared items shall be ready for review Monday at noon.
• Team members participating in the refinement book 1-hour time slot for Monday afternoon to get familiar with the items.
• The preparation work is considered by the Product Owner the previous Wednesday.
• The Product Owner identifies the right team member to prepare the item by Wednesday close of business.
• A team member has Thursday, Friday, and Monday morning to do the 20–30-minute preparation work.

Agreeing and sticking to these kinds of deadlines is, in my opinion, the only way a preparation process will work. Trying to agree on something different ad hoc will most likely fail.

Benefits of the disciplined preparation approach 

Development teams can benefit from the disciplined preparation approach in many ways:

• The entire team can count on the expertise of the team member who prepared the item. 
• Team members don't have to come up with everything in the item description or all the acceptance criteria. 
• The team can focus their attention and effort on challenging the preparation work and asking questions to determine if it missed something. 

After this practice becomes routine, the team can run through the items much faster and stop when there are uncertain parts of the description. The discussion skips the mundane and focuses much more on the high-value parts of the work.