Get certified - Transform your world of work today


Tips to Conduct Effective Joint Product Backlog Refinement Meetings in a Scaled Way

23 July 2014

If you have a plant in your garden and you do not take care of it through regular grooming, it grows in all directions and will become unmanageable over a period of time. So you spare some time to cut the extra branches, remove the dead leaves, apply pesticides, etc., to support the plant's healthy growth. Similarly, in Agile software development we also take care of the product in terms of removing the unwanted features, removing defects, ensuring that only valuable features are prioritized for implementation, etc. There is a specific event in Agile product development to conduct these activities. It is called product backlog refinement (aka, product backlog grooming), and it is a key event.

Product backlog refinement helps keep the upcoming backlog items discussed in detail and lined up for future sprints. This will improve the rhythm of the Scrum team, and by the time the team reaches the next sprint planning meeting, information about these items will be clear.

Definition of Ready

Definition of Ready (DOR) is a key artifact that has to be considered in product backlog grooming. The DOR is a criterion that will ensure that the stories groomed in the refinement meeting are "ready for the next sprint." The product owner and the team will discuss what should be the feasible DOR and agree on the items. Below are some important aspects that can be part of the DOR:
  • The story should have complete clarity from the "what" point of view.
  • It should be feasible to complete the story in one sprint (that means small in size).
  • The story should be testable (that means acceptance criteria is defined).
  • Any assumptions, constraints, and dependencies are identified and addressed.
  • The story should meet the INVEST principle.

What happens in the product backlog grooming meeting?

  • Discuss the stories to get clarity (only the "what" part but not the "how" part).
  • Split stories if they are large.
  • Merge stories if they are too small.
  • Discuss acceptance criteria.
  • Discuss the assumptions and constraints.
  • Identify dependencies.
  • Estimate the stories using story points.
When you are working as a single Scrum team on one product backlog, it will be pretty clear, and you may not see major issues in the product backlog grooming. However, when you have more than one team working on same product backlog, there will be some common issues observed. If we do not tackle these issues effectively, the session will become another general meeting without any valuable output.

What are the issues in joint product backlog grooming?

  • Timely starting of the meeting is very rare.
  • It takes longer than planned.
  • Very few stories are groomed, and they may not be enough for the next sprint.
  • Which team needs to groom the backlog item?
  • Should everyone from every team attend the backlog grooming? If so, is it time wasted?
  • Who will estimate the size of the backlog item?
  • Who will split the stories into technical tasks?
  • Teams tend to pick up easy stories and leave the hard stories behind.
  • More than one team wants to work on same story (when it is technically challenging/interesting).
  • Sometimes no team wants to work on a particular story (maybe it's not really challenging).

So how do we tackle these issues?

It is good to have a common working agreement in place to resolve the issues above. Scrum teams commonly have a working agreement at their team level when it is a single Scrum team working against a single product backlog. When there are more teams working against same product backlog, it will be useful to have a common working agreement across all the teams in addition to the team-level working agreement.

What will be part of the common working agreement?

  • Define a commonly feasible time for the meeting and get buy-in from all teams.
  • Define the approach for the teams to choose the stories in the product backlog grooming meeting. Some approaches you can try:
    • Round robin
    • Clockwise
    • Anti-clock wise
  • If for some reason one team cannot pick a certain story, then the next team has to pick it up.
  • Define a common baseline story and size it (better to have two baseline stories of, say, 2 and 5 or 3 and 8 story points).

Some useful tips to make the joint product backlog grooming effective:

  1. Before the meeting, ensure that the ScrumMasters from the respective teams check with the PO and have the backlog prioritized, with stories for further discussion at the meeting.
  2. The ScrumMasters should ensure that the team members are aware of this meeting and that they plan to come on time.
  3. The Definition of Ready should be prepared.
  4. Initially, let all team members, along with their ScrumMasters, attend the meeting and, based on the need, you can plan to have representatives from each team on a rotating basis. In this case, the representatives will go back and update their respective teams.
  5. Keep a specific timebox slot for each story grooming. If it is taking longer than that duration, someone should act as timekeeper and move to next story.
  6. All teams should respect the common working agreement.
  7. ScrumMasters should observe the behavioral atmosphere from this meeting and coach their respective teams on the areas that need improvement.
  8. Periodically review the DOR and common working agreements to update the suggestions or changes needed to make them effective.
  9. Try to apply lean principles, such as eliminating waste, differing the commitment wherever applicable.
  10. Encourage open and transparent interactions across the teams in the meeting.

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: 3.6 (8 ratings)


Michael James, CST,CSP,CSM,CSPO,REP, 10/27/2015 2:37:47 PM
Joint refinement is a good idea, but "definition of ready" seems to be doing more harm than good. We never have *complete* clarity about what the customer will ultimately want. As Ron Jeffries has put it, "a story is a promise for a future conversation." The more important thing is to connect the developers to the users throughout the Sprint for continuous learning.

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