Get certified - Transform your world of work today

Close

Good Product Backlog Refinement

How to develop a good product backlog refinement process for your Scrum team

7 October 2015

Samantha Webb
Riot Games


Sprint planning doesn’t have to be hard work. This ceremony takes place at the start of the sprint and allows the dev team and product owner to work together to agree and understand what items will form the sprint backlog for the upcoming sprint.

When we started out on our Scrum journey, sprint planning was always painful. With the added difficulty of being a distributed team, we often have to hold this meeting over videoconference with screen sharing. With half of the team inevitably being in an early-morning, pre-caffeine stupor and the others with rumbling stomachs at their lunchtime, sprint planning had the potential to run for hours. This left the team exhausted and sluggish, and it got the sprint off to a slow start, as well as leading us to write sloppy sprint goals due to everyone’s eagerness to get the meeting finished.
 
We soon learned that the key to good sprint planning was in a good product backlog refinement process.
 
Product backlog refinement, sometimes known as product backlog grooming, is not a defined ceremony within the Scrum framework. Instead, it is detailed as an activity, and Scrum teams are encouraged to commit approximately 10 percent of their sprint time in carrying out this activity.
 
The product backlog, the "wish list" of future product features, is the responsibility of the product owner to manage (with the ScrumMaster to help if necessary). Product backlog refinement sessions allow the PO to collaborate with the team to communicate ideas and work ensure that the vision is being translated into satisfactory user stories with clearly defined tasks.
 
There is no set structure for the product backlog refinement sessions, and it is down to each Product Owner and dev team to work out what suits them best. On my current team we have defined a process that works well for us, and this is what I want to share with you today.

PBR.png
 
Our process:
  1. Write user stories and define subtasks.
  2. Define acceptance criteria for the story.
  3. Estimate the tasks.
  4. Check against the definition of ready.
 
  1. We start by writing our user stories. This is led by the product owner, who will outline the user journey or feature that he wants to include. As a team, we create the user story following the standard "As a (user) I want to (some action) so that (some outcome)" formula. Following this, we start to examine the user journey and break it down into actionable subtasks. On our team we use Jira Agile, so the user stories and subtasks are written up in Jira and added to the product backlog.
  2. Once we have an agreed user story and a list of defined subtasks, we look at the acceptance criteria for the story. The acceptance criteria forms our checklist to ensure that, as a dev team, we understand the PO's expectation and what the user story's outcome and aim are. Acceptance criteria cover both functional and nonfunctional requirements and should be measurable, unambiguous, and testable. By assigning acceptance criteria to a story, we are able to ensure that the story is tested and working as expected.
  3.  We use story points to estimate through planning poker -- physical cards used during colocated sessions and virtual cards during distributed sessions. We currently do our estimation during the sprint planning meetings, but now that we are an established team and understand our velocity, we are making the move to estimating high-priority items during product backlog refinement sessions when we have the opportunity to do so. We will only estimate in sessions at which the entire dev team is able to attend.
  4. Finally, we check our story against our team’s agreed Definition of Ready. The Definition of Ready is a team document; an agreement between the dev team and the product owner of what is needed from a story to allow it to be brought into a sprint backlog. This is a single checklist that covers all stories; similar to acceptance criteria, a DoR should be measurable and clear. This is something we were not good at doing in our early sprints. We duly wrote a DoR as we knew a good Scrum team should, and then we were so overwhelmed by the transition to the Scrum process that we forgot to look at it again. We revisited our Definition of Ready, refined it, and now ensure that a story has all its prerequisites. Once the story meets the DoR, the dev team effectively confirms to the product owner that the story is "sprint-ready" and can be added to the next sprint backlog if its priority allows this.
By refining your refinement process, you should be able to effectively manage your product backlog and streamline your sprint planning meetings, leaving your Scrum team more energized and ready to start the sprint.

 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (12 ratings)

Comments

Anonymous, 10/8/2015 8:22:22 AM
This was a very helpful article. As soon as I read the sentence, "When we started out on our Scrum journey, sprint planning was always painful...." I knew that this was the post for me.
Sayi Sarat Chandra Parvatam, CSP,CSM,CSPO, 10/13/2015 9:25:38 AM
Good piece of information :)
Pratheesh P K, CSP,CSM, 10/14/2015 11:56:54 AM
Thanks so much for explaining product grooming activities in a step by step manner. Its really helpful.
Leonel Zapien Lopez, CSM, 10/19/2015 7:26:09 PM
Refining the backlog, as much as I can see in most of the projects that I have been, is a critical step, and I agree about what you mentioned and the process that you used to keep the backlog refined.
I just would like to add that the backlog grooming is not a one-time task, but a never ending process.
Thanks for sharing.
Anonymous, 11/12/2015 8:30:31 PM
"When we started out on our Scrum journey, sprint planning was always painful...." - we just start
Florian Huber, CSP,CSM,CSPO, 11/13/2015 1:32:34 AM
Samantha, I like that you are emphasizing the importance of refining the backlog as a ongoing activity during sprints.
I have two matters to highlight:
1) I am just puzzled that your team defines the sub-tasks before the PO provides the acceptance criteria. I'd expect that in your given order, you might need to refine the subtasks again.
2) As a result of your refinement you gain an estimated, ready-for-sprint, story broken down sprint backlog. Which is considered the second part of a planning. What are the remaining activities during a planning? Defining the sprint goal, a mere nodding and "let's go!"?
Cheers, Florian
Matt Barwick, CSM, 11/13/2015 4:56:23 AM
Hi
Overall a good article. I do agree with Florian though - I think having acceptance criteria already written really helps when writing subtasks as you know all the points that you need to cover.
Ahmet Yilmaz, CSPO, 11/13/2015 7:31:44 AM
Samantha, great to see the refinements coming through from a practical perspective. A lot of teams assume you less discipline due to the 'Agile' method, but once again this demonstrates that more structure, collaboration and discipline is needed. Well Done
Mindy Waters, CSM, 11/13/2015 7:43:44 AM
Great article, I agree with Florian as well regarding not defining the subtasks until the acceptance criteria has been defined and approved by the PO.
Sivakrishna Sreekaram, CSM, 12/22/2015 2:53:39 AM
Good Info
Andrea Goldsmith, CSM,CSPO, 1/5/2016 7:16:34 PM
I would advise disuse of the term "grooming" in favor of "refinement". As I learned in my CSM certification course, and encountered first hand in managing an international project, it has very pejorative connotations in some cultures.
Anonymous, 8/31/2016 11:12:53 AM
Would you be willing to share your Definition of Ready checklist?
VADIVELAN NATARAJAN, CSM, 9/25/2017 11:53:02 AM
Good and Informative. Thank you

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe