Product Backlog Management
•Download as PPTX, PDF•
11 likes•8,353 views
Product Backlog Management for Scrum and Agile Projects
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Product Backlog Management
Similar to Product Backlog Management (20)
More from Silvana Wasitova, Scrum & Agile Coach
More from Silvana Wasitova, Scrum & Agile Coach (20)
Recently uploaded
Recently uploaded (20)
Product Backlog Management
- 1. Agile Product Backlog Management Silvana Wasitova, CSM, CSP, CSPO, PMP, ACP Bucharest, November 2013
- 2. Why do these companies use Agile Methods?
- 5. Scrum : Summary Product Owner Team Scrum Master Product Backlog Sprint Backlog Potentialy Shippable Product Burn-down Chart Product Planning Sprint Planning Daily Scrum Sprint Review Retrospective Cardinal Rule: Work on the highest priority item first
- 6. Product Owner 6 Define features of the product Decide on release date and content Responsible for product profitability / ROI Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results
- 9. Stakeholders
- 10. Users
- 13. Risk Management
- 16. 3.4 billion pageviews in 1 month
- 17. Yahoo-Eurosport: 2008 Event Schedule TDF Euro Paris-Dakar January Tour de France February Rugby 6 Nations March April Rolland Garros FOOT: Olympic Games qualifiers World Cup qualifiers 17 7-Nov-13 May June Wimbledon Moto GP Golf, Athletics, Cycling Basketball Boxing Horse Racing Hockey, etc Year long project, 2-wk sprints
- 18. Managing the Product Backlog Initial Ready Refined R 1 End of S1 S 1 R 1 S 2 S 2 S 3 S 3 S 4 S 4 R 2 R 2 R 3 R 3 R 2 R 3 R 2 R 3
- 19. Scope Management
- 20. Example - Release Plan – initial version Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Planned Go Live Test Env’t Mega Menu Top Nav Bottom Nav Top Right Nav Global Nav (Toolbar) Bottom Nav Left Nav Authoring, Content Mgmt Search News Rollup Prep for Cutover MAT Portal Integration People Picker Left Nav Breadcrumbs Ongoing activities: update taxonomy 7-Nov-13 version VST VST Feedback MAT Feedback Wizzard Comms Panel Part 1 Comms Panel Part 2 Comms Panel Part 3 Actual Go Live
- 21. 3 MONTHS Scrum vs. Waterfall: Time To Market Faster Time to Market Higher Quality Satisfied Customer Scrum Develop & QA Spec Collaborative Results-Oriented 6-10 MONTHS 9 weeks Waterfall 3 months Develop & QA Spec Updates 12 weeks x wks y wks 6-10 months © Silvana Wasitova 3-6 wks Sequential Process-Oriented
- 22. Budget & ROI
- 23. Delivering Business Value Scope Definition Specs Develop QA Regression Deploy Business Value deliver business value all at once Waterfall ROI ROI Scrum Sprint 1 Sprint 2 deliver business value in ea iteration: Dev, QA, docs, integration test 23 Sprint 3 Sprint 4 Sprint 5 Time
- 24. 64% implemented features are rarely or never used Sometimes 16% Rarely 19% Often 13% Always 7% Never 45% Ref: Jim Johnson, Chairman of Standish Group, quoted in 2006 in: http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS Sample: government and commercial organizations, no vendors, suppliers or consultants
- 26. 26 Release Planning • Projects may have multiple Releases (optional) • Each release likely has multiple Sprints • Stories are started and completed in one Sprint • Stories are executed based on value and priority
- 27. User Story Map Required Essential Important Optional “Backbone and skeleton” Identify the “Minimal viable product”
- 28. Agile deals with Ziv’s Law: Humphrey’s Law: Wegner’s Lemma: Langdon’s Lemma: 28 •Specifications will never be fully understood •The user will never be sure of what they want until they see the system in production (if then) •An interactive system can never be fully specified, nor can it ever be fully tested •Software evolves more rapidly as it approaches chaotic regions (without spilling into chaos)
- 30. Agile Philosophy Adapt to changing requirements throughout dev. cycle Stress collaboration between developers and customers Early product delivery Strip-off non-essential activities & artifacts Transparency: daily standup Regular reviews with Client/Product Owner Continuous improvement via Retrospectives
- 31. 2012 survey, 4000+ respondents
- 32. Top Three Reasons 2012 survey, 4000+ respondents Accelerate Manage Better time to market changing priorities align IT & business objectives
- 33. Silvana Wasitova, PMP, ACP, CSM, CSP, CSPO wasitova@yahoo.com +41 79 558 05 09 slideshare.com/wasitova
- 35. References http://scrum.jeffsutherland.com http://scrum.jeffsutherland.com/2013/10/what-heck-is-business-valueanyways.html http://www.scrumalliance.org/ http://www.mountaingoatsoftware.com http://www.agilealliance.org Speed of Change: http://blog.jackvinson.com/archives/2010/12/31/resilience__managing_at_the_speed_of_change.html
- 36. Scrum Origins Jeff Sutherland • • Initial scrums at Easel Corp in 1993 IDX and 500+ people doing Scrum Ken Schwaber • • Co-presented Scrum at OOPSLA 96 with Sutherland Author of three books on Scrum Mike Beedle • Scrum patterns in PLOPD4 Ken Schwaber and Mike Cohn • Co-founded Scrum Alliance in 2002, initially within the Agile Alliance 36
- 37. Agile & PMBOK Agile processes reflect PMBOK process groups: Initiating, Plan, Execute, Monitor/Control, Close In each iteration: • Plan, Execute, Monitor, Control • Scope, time, cost and quality management
- 38. Reading List • Agile Project Management with Scrum by Ken Schwaber • Agile Estimating and Planning by Mike Cohn • Agile Retrospectives by Esther Derby and Diana Larsen • Agile Software Development with Scrum by Ken Schwaber and Mike Beedle • Scrum and The Enterprise by Ken Schwaber • Agile and Iterative Development: A Manager’s Guide by Craig Larman • User Stories Applied for Agile Software Development by Mike Cohn Sites: • ScrumAlliance.org • JeffSutherland.com
Editor's Notes
- adaptive planning as opposed to traditional planning, evolutionary development and delivery, and encourages rapid and flexible response to changeRead more: http://www.crunchbase.com/company/scrumstudy-com-a-leading-brand-from-vmedu-inc#ixzz2jrzwhgqE Follow us: @crunchbase on Twitter | crunchbase on Facebook
- http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar Eric S. Raymond on software engineering methods, based on his observations of the Linux kerneldevelopment process and his experiences managing an open source project, fetchmail. It examines the struggle betweentop-down and bottom-up design. It was first presented by the author at the Linux Kongress on May 27, 1997 in Würzburgand was published as part of a book of the same name in 1999.Cost of delay is central to decision making. It drives the right conversations and decisions around cost and revenue, rather than just the unbalanced conversations of cost many IT divisions suffer today. Cost of delay is the right tool for proper prioritization decision.Lifetime ProfitabilityThe cost of delay isn’t a simple calculation for most projects. Individual project deliverables have highly speculative and uncertain value propositions (until a customer pays, uptake rate is subjective). Also its speculation how any delay will cause competition to take more of your market share impeding lifetime value. Given its hard on a single project, calculating the compounding impact on other delayed projects in your portfolio (given your staff are still finishing this one) makes for a mind-blowing forecast equation for cost of delay. This is what we want to solve for you. Using the same models you use for planning and managing projects we build a consolidated picture of revenue and cashflow considering all aspects of cost of delay.Our Cost of Delay RoadmapThe software industry is new to calculating cost of delay. Whilst we believe we are the leaders in this area (combining probabilistic forecasts for cost of delay calculations) it is an unpaved road we are travelling on. We are willing to put our plans on the table to show where we intend to be in the next few years and where we currently are -Now: Linear lost revenue calculations plus cost of developmentWe implemented this in our KanbanSim and ScrumSim v1.3.1. We correctly calculate the lost revenue from a given target date. Revenue is modeled as a fixed value per unit of time (day,week,month,year). This simple calculation gives an accurate portrayal of lost immediate revenue but UNDERESTIMATES cost of delay by ignoring compounding impact on other projects and lost market share from being late.2013: Compounding Dependent ProjectsDependent projects that are either pre-requisites or delayed by another project should add to the cost of delay calculations. We are beginning to model dependency trees in order to cascade cost of delays and the latest delivery forecasts into the cost of delay calculations. We feel that any portfolio planned without considering these cascading dependencies is flawed and looking forward to offering the first viable solution that helps muddle through the complexity of this planning process.2013-2014: Lost product life-time profits (market share, competitive pressure losses)How much would have google made (or Apple lost) if Google had Android on the market 12 months earlier? This is the type of analysis we are adding to our modeling language to obtain a more accurate picture of life time product harm by a delay. This is the holy grail of portfolio planning and prioritization and we are VERY excited to have the right groundwork to do this analysis with statistical rigor.
- Risk: Uncertainty that matters,Uncertain eventProbability and Impact
- Cost of delay is central to decision making. It drives the right conversations and decisions around cost and revenue, rather than just the unbalanced conversations of cost many IT divisions suffer today. Cost of delay is the right tool for proper prioritization decision.Lifetime ProfitabilityThe cost of delay isn’t a simple calculation for most projects. Individual project deliverables have highly speculative and uncertain value propositions (until a customer pays, uptake rate is subjective). Also its speculation how any delay will cause competition to take more of your market share impeding lifetime value. Given its hard on a single project, calculating the compounding impact on other delayed projects in your portfolio (given your staff are still finishing this one) makes for a mind-blowing forecast equation for cost of delay. This is what we want to solve for you. Using the same models you use for planning and managing projects we build a consolidated picture of revenue and cashflow considering all aspects of cost of delay.Our Cost of Delay RoadmapThe software industry is new to calculating cost of delay. Whilst we believe we are the leaders in this area (combining probabilistic forecasts for cost of delay calculations) it is an unpaved road we are travelling on. We are willing to put our plans on the table to show where we intend to be in the next few years and where we currently are -Now: Linear lost revenue calculations plus cost of developmentWe implemented this in our KanbanSim and ScrumSim v1.3.1. We correctly calculate the lost revenue from a given target date. Revenue is modeled as a fixed value per unit of time (day,week,month,year). This simple calculation gives an accurate portrayal of lost immediate revenue but UNDERESTIMATES cost of delay by ignoring compounding impact on other projects and lost market share from being late.2013: Compounding Dependent ProjectsDependent projects that are either pre-requisites or delayed by another project should add to the cost of delay calculations. We are beginning to model dependency trees in order to cascade cost of delays and the latest delivery forecasts into the cost of delay calculations. We feel that any portfolio planned without considering these cascading dependencies is flawed and looking forward to offering the first viable solution that helps muddle through the complexity of this planning process.2013-2014: Lost product life-time profits (market share, competitive pressure losses)How much would have google made (or Apple lost) if Google had Android on the market 12 months earlier? This is the type of analysis we are adding to our modeling language to obtain a more accurate picture of life time product harm by a delay. This is the holy grail of portfolio planning and prioritization and we are VERY excited to have the right groundwork to do this analysis with statistical rigor.
- Scope Creep
- Focusing on customer needs ensures:the right features are builtnot wasting effort (and resources) on features that are not neededThe figures may be different in Nestle,Principle remains:Only build the features that the client/users need
- 4000+ respondents in 2012