Product Backlog Refinement (PBR)

Product Backlog Refinement (PBR) – The Art of getting Stories to READY state

When defining requirement in Product Backlog, Product Owner can take liberty of not defining the detailed requirement, in fact it can be even a single line. However, as the requirement moves from Product Backlog to Sprint Backlog, it should be detailed enough for team to estimate size and effort, and break down to task

Product Backlog Refinement (PBR) is the Responsibility of the Scrum Team

Scrum Team need to refine the use stories (Add Details, Estimates) to Product Backlog Items (PBIs) in the Product Backlog

PBR is an activity that should happen on an?Ongoing Continuous Basis (every week)

 Purpose:	Adding more details,estimates & ordering to Product Backlog Item

 Duration:	As much as needed, usually 10% the Development Team Capacity

 Attendants:	Scrum Team, and possibly end-users or Stakeholders

 Inspection:	Product Backlog

 Adaptation:	Product Backlog Items

 Transparency:	Clarification of possible upcoming work

 Tools / Techniques:	Planning Poker, T-Shirt Sizing, DoR, Slicing

 Participants:	        Product Owner, Development Team, Scrum Master,    Architect, SME, if requireds        

Importance of Ready (Definition of Ready – DOR)

“READY” IS AN MINDSET

Working with self-organizing Development Team is powerful, and you will be amazed at what they can deliver

Self-organization has its limits

Garbage IN?à?Garbage OUT

If you feed garbage into the Sprint, you most likely will get garbage as Output.

In other words, if you are not “Ready” at the beginning of the Sprint, you won’t be “Done” at the end of Sprint.

Note: You should not be doing refinement of Stories that you have already committed to current sprint. If you are, its too late, and the Team is setup for failure!

Features are decomposed into small user stories so that they can be completed within a sprint. User Stories are smallest units of business and technical requirements

?User Stories in the Product Backlog exist at different levels of detail depending on their priority and when they will be developed.

User Stories must be refined to the point they meet the Definition of Ready so that they can be candidate for Sprint Planning

Above diagram explain the how the Refinement of User Stories happen – PBR (Product Backlog Refinement) should target next 2 future Sprints (Sprint+1 & Sprint+2), next 2 sprints stories should be estimated and refined, Team should also the what’s velocity of Team so that based on that refinement can be done.

User Stories elaboration happen in Backlog Refinement

Slicing / Decomposition should not happen horizontally i.e. there should not be user stories which only cater one layer of the application i.e. UI or Database or middle tier rather user stories should be vertically sliced and cater all the layers of the application.

Important Points for Product Backlog Refinement

• PO explains the Feature / Epic & Stories (work slice) that s/he want to refine.
• PO explains the business context, needs and value
• User Story writing workshop to get the team familiar with Story writing and slicing
• Goal is to discuss Product Backlog Items as a Group, understand them, and be able to slice them into smaller chunks
• 3 Amigo, PO, Dev and QA should together (whole Team should attend PBR and refine) refine user stories so that each bring different prospective as well as how story need to be tested
• Ask Questions if not clear about the functionality being asked
• Estimation of Epics – It can be done either in T-Shirt Sizing or number of sprints or Story Points & It should happen at least 1-2 release in advance so that PO can forecast and do release planning
• Agree on scope of the Work Slice & 3 Sprint running average can be used as the Velocity
• Estimation of User Story – Get the estimates from the Team using Planning Poker (Modified Fibonacci numbers) called as Story Points (SP)
• User Stories should not be more than 8 Story Points wherever possible, so that it can be easily complete with the Sprint
• Acceptance Criteria
• Does the Team understand Acceptance Criteria?
• Are the Acceptance Criteria SMART?
• If required, amend Acceptance Criteria
• Verify Acceptance Criteria (AC) with PO if Team or BA wrote A/C
• How can one slice large Stories into Smaller sizes / pieces? – Slicing should not happen horizontally i.e. there should not be user stories which only cater one layer of the application i.e. UI or Database or middle tier rather user stories should be vertically sliced and cater all the layers of the application
• Consider Different Users, Roles and Persons in the Story Description
• ROI
• Different Priorities
• Different Levels of Risks
• Dependencies
• Logical Groups, Data Boundaries
• Use Patterns for Slicing
• Product Management Techniques (i.e. Story Mapping)
• How the Product Backlog would be ordered
• Prioritization Techniques i.e. WSJF, MoSCoW and based on Business Value
• Discuss what tasks would have to be carried out to complete the story
• Do we need to write a SPIKE story to recognize and separate any research activity?, What are the dependencies?
• Have we separated the dependencies, so that the team has an “independent” story that can be worked on?
• Does the work slice / user story meet INVEST criteria?
• Get the smaller slices to READY state
• Do all the stories bubble up to Epic / Feature, there should not be any orphan User Stories not connecting to Epic / Feature
• Team should be doing refinement regularly (every week)
• PO need to continuous order the Product Backlog, the highest priority user stories should be done first, prioritize user stories deliver the greatest business value

Note: Refinement is more of ‘forward looking’ event, and can improve Quality of Sprint Planning as well as Success of the Sprint for the Team