Agile Product Ownership
•Download as PPTX, PDF•
2 likes•107 views
The document discusses several challenges and best practices for product ownership in agile development. It questions how success is defined and whether the right features are being prioritized. It suggests that product owners should evaluate feature impact on business and customer usage, and ensure the backlog comes from product design decisions validated through experimentation rather than upfront requirements alone.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile Product Ownership
Similar to Agile Product Ownership (20)
Recently uploaded
Recently uploaded (11)
Agile Product Ownership
- 1. Agile Product Ownership Dr. David Michel david.michel@tessella.com @DavMichel76
- 2. Quick questions before we start…
- 6. What’s your definition of success?
- 7. Feature A Feature B Feature C Are you running a Feature Factory ?
- 9. Scope On Time Outcome Win?
- 13. Questions we are interested in… • Did this deliver value to the customer? • What impact did it have on their business? • Are they actually using the software? • Are we building the right thing? • Are we on track? • How are we doing in terms of budget? • Will we be able to finish in time?
- 14. EPIC Features Mr. Product Owner The Team The conversations should include: • How do we assess the impact on the business? • How do we judge whether this was the right thing to build?
- 16. Where does the Product Backlog come from?
- 17. Tim e # stories Stories when created Stories when developed/done • The PO knows what ought to be developed up front. • The dev team works on hardest/riskiest items first, leaving the easier ones for later (so they are faster at the end) • Predicted end date converges to the left has time passes.
- 18. Tim e # stories Stories when created Stories when developed/done • The dev team works on the easier first, leaving the hardest/riskiest for later… • Culture where team is desperate to appear busy? • End date every hard to predict
- 19. Backlog with stories of different size and level of refinement Priority • Useful for the dev team to have the highest priority items as the smallest, and most refined items • BUT, the fact that a story is unclear does not mean is has low value or is not important! • Those stories should perhaps be the ones to be worked on sooner rather than later! • The criteria for priority should be value/risk, not “known”
- 20. Tim e # stories That’s the ideal curve, when the Product Owner knows what he/she is doing When you’re constantly learning from feedback (i.e. when you are agile)
- 21. Tim e # stories Stories when they are created Stories when are developed/done • You need something else to measure progress – Cannot tell when you’ll be finished • You need to become value- driven, with different kind of metrics
- 22. 22 Kano Model
- 23. You’ll need more than a simple backlog!
- 26. Story Mapping
- 27. Story Mapping
- 28. Impact Mapping
- 29. Impact Mapping
- 31. Where does the Product Backlog come from?
- 33. If it’s your decision, it’s design. If it’s not, it’s a requirement “ ”
- 34. Product design decisions need to be tested & validated Just like technical ones are
- 35. Discovery Delivery Figuring out what to build Then build it • No validation of product design decisions • Which are all made up front
- 39. • Pay-to-learn: iterative, innovative, discovery, deliverables = learning outcomes • Build-value: incremental, progress metrics = # stories completed • Trim-the-tail: Kanban, refinement before a release Disciplined Learning: Risk Reduction = Knowledge Acquisition
- 40. How do you validate the learning? Minimal Viable Product Experiment
- 42. Effort
- 43. Effort
- 47. Effort Confidence Lunch Holiday Car House Stupid & Expensive Stupid & Wasting time These are all MVE tests!
- 48. Effort Confidence Lunch Holiday Car House Stupid & Expensive Stupid & Wasting time These are all MVE tests!
- 49. Learning from user interviews
- 50. ?