Backlog Refinement in an Agile Environment


I’m going through the Agile Practice Guide on a systematic basis to review all of its contents.   Chapter 5 covers the implementation of a project in an agile environment.

Section 5.2 of this chapter covers the eight most common agile project practices, which are:

5.2.1 Retrospectives

5.2.2 Backlog preparation

5.2.3 Backlog refinement

5.2.4 Daily Standups

5.2.5 Demonstrations/Reviews

5.2.6 Planning for Iteration-Based Agile

5.2.7 Execution Practices that Help Teams Deliver Value

5.2.8 Iterations and Increments Help Deliver Working Product

I covered the first two items on the list, retrospectives, in the last few posts.   The previous item was the preparation of the backlog, done by the product owner.   Now I’ll start on the third item, which is backlog refinement.    This is where the product owner takes the backlog he or she created and takes it to the team for … well, refinement.

What does “refinement” mean in this case?

  1. The team has to understand what the stories mean, so that if the description by the product owner was not sufficient, the team can ask the product owner questions to make sure the meaning is clear.   If the team finds that there are potential challenges or problems in the stories, then the product owner can request the team to spike the feature in order to further explore the risks involved before committing to it.
  2. The team has to understand how large the stories are in relationship to each other.  This is key to planning in an agile environment (this is an item to be discussed in a later post).

What should the format of the refinement meeting be?   There are several ways of going about it:

  • Just-in-time refinement (for flow-based agile).   The team takes the next card off the “to-do” column and discusses it.
  • Iteration-based refinement, done for one hour midway through an iteration.
  • Multiple refinement discussions for teams that are new to the product area.

In any case, the Guide recommends that the refinement meeting not be more than one hour per week.   If the team is spending more time than this, it could be that the team may be lacking the critical skills needed to evaluate and refine the work.

One interesting possibility that the Agile Practice Guide mentions is the combination of the backlog preparation and backlog refinement.   This is where the team participates in the preparation of the backlog, and not just its refinement.

Here again, the Guide suggests several ways of going about this combined process:

  • The product owner presents the overall story concept to the team, and have the team discuss it and refine it, splitting it into several stories if needed.
  • The team splits into three groups taking the roles of a developer, tester, and business analyst/product owner to collaborate in writing the story.   With input from all three groups, the story should end up being understood by all of the team.
  • The team works on producing stories on a daily basis that are small enough so that they can be completed in a single day.   This will ensure that the team can complete a steady flow of completed work.

Whether the product owner does the backlog on his or her own, and THEN presents it to the team for refinement, or works with the team to create and refine the backlog, the end point is the same.   The team should understand the stories well enough to estimate their size, prioritize them, and then get to work!

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: