PBR – what the team always needed to know before starting implementation

The Product Backlog Refinement sometimes also called Grooming is an activity that typically takes part one week after the Sprint Planning in a two weeks sprint. In longer sprints it takes place mostly half way through the sprint.
But what is PBR? What do we have the Product Owner (PO) for? Isn’t it his job to detail out all information about what to implement and then officially hand that over at the sprint planning so the team can start doing their magic and show their results in the Sprint Review?
For those of you new to Agile and Scrum: the truth is no longer in the documents, it’s now shared understanding that exists in all the heads of Customer, PO and Scrum Team.
The PBR has 3 main purposes which you can see in pink in the picture:
  1. Clarify the backlog items so everyone has the same understanding
  2. Splitting up too big stories/features
  3. Estimation as preparation of the sprint planning and also check for the size of the product backlog items

A good PBR has some pre-requisites

  1. the PO prepares the Backlog
    1. Details out stories with the help of the customer keeping mostly the Customer and Business Value in focus 
    2. Prioritises the backlog according to the Vision and Roadmap
    3. Tidies up stories/items that are no longer needed or deprecated
    4. splitting down features into stories
    5. talking the resulting backlog through with the customer to make sure Business and Customer value are understood right and all use cases and scenarios have been captured 

Doing the PBR

  1. the PBR is a join effort of
    1. PO
    2. the cross functional Team (including everyone who is working on the project)
    3. Scrum Master to help with the facilitation
  2. The whole above mentioned group together starts going through all items to:
    • identify big or vaguely analysed items
    • analyse/split items
  3. Doing the PBR is best done with hands on material like cards, post-its, flip-charts, whiteboards. Try to avoid using a computer and staring with 5-8 people on a screen, this will cause another form of “death by powerpoint”.


Ultimately the outcomes of the PBR is learning and shared understanding by talking to each other.
It is NOT a desired outcome to have user stories that have extremely specified information in form of pages and pages of text. This would cause one of the lean wastes of “handover”.

One thought on “PBR – what the team always needed to know before starting implementation

  1. Pingback: You’re first Sprint as a Product Owner | Product Owner Toolbox

Leave a Reply

Your email address will not be published. Required fields are marked *