Downloaded 288 times
Uploaded bySilvana Wasitova, Scrum & Agile Coach
Product Backlog Management
The document provides an overview of agile product backlog management using the Scrum framework. It discusses key aspects of Scrum including the product owner, sprint backlog, product backlog, daily stand-ups, sprint reviews and retrospectives. The document also compares Scrum to the waterfall method and discusses benefits of Scrum such as faster time to market, higher quality and satisfying customers through iterative delivery of working software.
More Related Content
Similar to Product Backlog Management
More from Silvana Wasitova, Scrum & Agile Coach
![Support, Monitoring, Continuous Improvement & Scaling Agentic Automation [3/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day3-cfd-251120170304-ddef8112-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Full-Stack Development] The Modern Stack: Building Web & AI Appli...](https://cdn.slidesharecdn.com/ss_thumbnails/fs-themodernstackbuildingwebaiapplicationswithserverless-251124030844-388cf04f-thumbnail.jpg?width=640&height=640&fit=bounds)
Product Backlog Management
- 1. Agile Product Backlog Management SilvanaWasitova, CSM, CSP, CSPO, PMP, ACP Bucharest, November 2013
- 2. Why do thesecompanies use Agile Methods?
- 3.
- 4.
- 5. Scrum : Summary ProductOwner 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 featuresof 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
- 7.
- 8.
- 9.
- 10.
- 13.
- 14.
- 15.
- 16. 3.4 billion pageviewsin 1 month
- 17. Yahoo-Eurosport: 2008 EventSchedule 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 ProductBacklog 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.
- 20. Example - ReleasePlan – 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.
- 23. Delivering Business Value ScopeDefinition 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 featuresare 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
- 25.
- 26. 26 Release Planning • Projectsmay 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 “Backboneand skeleton” Identify the “Minimal viable product”
- 28. Agile deals with Ziv’sLaw: 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)
- 29.
- 30. Agile Philosophy Adapt tochanging 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 2012survey, 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 • • Initialscrums 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 ProjectManagement 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
- #3 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
- #8 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.
- #14 Risk: Uncertainty that matters,Uncertain eventProbability and Impact
- #15 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.
- #20 Scope Creep
- #25 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
- #32 4000+ respondents in 2012