Improve your Product Backlog Refinement (PBR) Process
0 likes966 views
The document provides guidance on conducting effective Product Backlog Refinement sessions, including splitting user stories, estimating effort, focusing on business value, and collaborating with stakeholders. It emphasizes refining items into testable increments and considering both positive and negative scenarios to ensure stories are appropriately sized. Stakeholders should be engaged as collaborators to provide input and help the team learn.
Improve your Product Backlog Refinement (PBR) Process
- 1. Learn to Learn with healthy Product Backlog Refinement process. 2020
- 3. Groups of Teachers and learners
- 4. A team learning from an expert
- 6. The Scrum Guide Says… “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. … During Product Backlog refinement, items are reviewed and revised.”
- 7. ”Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog... “
- 9. Try USE TEACHING/LEARNiNG TOOLS youtube.com/watch?v=NLn_mzCfhKw
- 14. Try not usingEpics (because they make you focus on wrong things)
- 15. ???
- 16. Instead: (maybe) think of stones Boulders Rocks Stones Pebbles Gems
- 17. Size and value don’t corelate really
- 20. FLOW OF PBR Item size Level of details LARGE& UNREFINED SMALL & UNREFINED CLEAR, TESTABLE &FEASIBLE © Roman Pichler 1. ESTIMATE 2. SPLIT 3. REFINE
- 21. Product Backlog Dev Team Payment DB Payment API Payment Validation Payment UI Technical Split one sprint one more sprint one more sprint ???
- 22. Complex negative scenarios Complex negative scenarios User is informed if card is not valid INSTEAD Split BY BUSINESS VALUE Payment Payment with Visa Payment with MasterCard Payment with PayPal First positive scenario Complex negative scenarios User can store card data for further usageToo big for a sprint User is informed if card is not valid Still too big for a sprint Card validations
- 23. Stakeholders “Buying” Features id theme title estimate sprint bigger picture url 101 payments Visa: expired card 5 s-5 confluence/payments 102 payments Visa: blocked card 8 s-5 confluence/payments 103 payments Visa: success (no fund check) 5 s-5 confluence/payments 104 user profile Avatar: upload (fixed size) 5 s-6 confluence/avatars 105 user profile Avatar: upload (cropping) 13 s-6 confluence/avatars 106 user profile Password: auto expiration 2 s-7 confluence/pwd_rules Flat backlog example
- 24. VALUE MINING
- 28. Try visual splitting (at awhite-board) linkedin.com/pulse/what-i-tell-yourequirements-like-bubbles-alexey-krivitsky/
- 29. Ablack hole
- 30. Splitting in action - certainty and value are clear
- 35. PBR sessions are events inLeSS! Thanks god! http://www.less.works/
- 36. IMPORTANT keep satisfied INFLUENCE INTEREST OTHERS monitor KEY PLAYERS manage closely AFFECTED keep informed Simplified stakeholder map “Bad guys”
- 37. Turn stakeholders into collaborators That guy
- 39. Classical Scrum Dilemma (coming from misunderstanding the PO role) Product Owner vs Stakeholders “How to make sure PO doesn’t lose control when the teams are in direct contact with stakeholders and experts?”
- 40. try focus on the bigger picture This guy
- 42. try focus on the bigger picture Agenda of a PBR session: Step 1: Bigger Picture (by PO) Step 2: Idea Pitching (by Stakeholders) Step 3: Forming Mixed Groups and Agenda (with the little help of Scrum Masters) Step 4: Learning Starts (Team Members and Stakeholders) This guy This guy
- 43. Try facilitating PBRs as interactive workshops “World Café” style 1. Stakeholders as station hosts. 2. A topic per station. 3. Groups rotate across all stations and all learn and contribute to all topics (every 12-20 minutes). 4. => Everyone knows all the topics but in some details. Good stuff! “Open Space” style 1. Stakeholders as session hosts. 2. A topic per session. 3. Groups decide which topics they are interested in and attend those sessions (45-60 minutes). 4. => Only some people know specific topics but in greater details. Good stuff!
- 44. Try focusing on the outcome (instead of features) Features (Output) 1. Focus is on features. 2. Discussions are around scope, schedules, estimates… 3. Game is about bargaining (zero-sum game). Can lead to mediocre solutions and boredom in teams due to lack of freedom and creativity. Impact (Outcome) 1. Focus is on user behavior and metrics. 2. Discussions are around impact and desired change. 3. Game is about coming up with minimal product changes to trigger desired behavior impact (win-win-win). Can lead to more employee engagement, cooler solutions and better scope management (surprise!).
- 47. Learn to Learn with healthy Product Backlog Refinement process. 2020 Thank you. This was: