Product Backlog Management

5,448 views

Published on

Product Backlog Management for Scrum and Agile Projects

Published in: Technology, Business
1 Comment
7 Likes
Statistics
Notes
  • Good presentation, thanks. Something about a year ago I've been to a lecture about Scrum and the guy showed us similar things, he mentioned Kanban as a good way to manage product backlogs. I tried to know more, one of my favourites articles about it is http://kanbantool.com/blog/how-to-deal-with-an-ever-growing-backlog and your presentation will be remembered too ;)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
5,448
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
189
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide
  • 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
  • Product Backlog Management

    1. 1. Agile Product Backlog Management Silvana Wasitova, CSM, CSP, CSPO, PMP, ACP Bucharest, November 2013
    2. 2. Why do these companies use Agile Methods?
    3. 3. About me Waterfall Agile
    4. 4. Scrum Framework
    5. 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. 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
    7. 7. Cost of Delay Market Opportunity Demand
    8. 8. The Product The Backlog
    9. 9. Stakeholders
    10. 10. Users
    11. 11. Risk Management
    12. 12. http://www.flickr.com/photos/bmhkim/4192236972
    13. 13. http://www.webbizideas.com/tutorials/local-seo/content-ideas-answers.html
    14. 14. 3.4 billion pageviews in 1 month
    15. 15. 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
    16. 16. 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
    17. 17. Scope Management
    18. 18. 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
    19. 19. 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
    20. 20. Budget & ROI
    21. 21. 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
    22. 22. 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
    23. 23. http://webwhiteboard.com
    24. 24. 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
    25. 25. User Story Map Required Essential Important Optional “Backbone and skeleton” Identify the “Minimal viable product”
    26. 26. 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)
    27. 27. http://www.flickr.com/photos/janex/38847936
    28. 28. 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
    29. 29. 2012 survey, 4000+ respondents
    30. 30. Top Three Reasons 2012 survey, 4000+ respondents  Accelerate  Manage  Better time to market changing priorities align IT & business objectives
    31. 31. Silvana Wasitova, PMP, ACP, CSM, CSP, CSPO wasitova@yahoo.com +41 79 558 05 09 slideshare.com/wasitova
    32. 32. 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
    33. 33. 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
    34. 34. 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
    35. 35. 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

    ×