O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Keeping Product Backlog Healthy

7.430 visualizações

Publicada em

The Product Backlog drives the work of Scrum teams, but keeping the backlog fresh and useful is often a continuing challenge. Is your product backlog healthy, and what are some ways to keep it that way that you can use right away?

  • Seja o primeiro a comentar

Keeping Product Backlog Healthy

  1. 1. Keeping a Healthy Product Backlog<br />Dhaval Panchal, CST and Agile Coach<br />
  2. 2. Dhaval Panchal<br />Certified Scrum Trainer (CST) and Agile coach <br />Consults with organizations from mid-sized product companies to the Fortune 100<br />Experience in software development, business and functional analysis, Lean office implementations, organizational change, system architecture, business intelligence, and project management<br />Writes about software development and coaching on his blog(http://dhavalpanchal.gettingagile.com/)<br />Received his B.S. in Engineering University of Mumbai, India<br />
  3. 3. Product Backlog: Point of View<br />Maximize ROI<br />Manage Risk<br />Balance Workload<br />Enhance Value<br />
  4. 4. Project Vision Drives the Features<br />Waterfall<br />Agile<br />The Plan creates<br />cost/schedule estimates<br />The Vision creates<br />feature estimates<br />Constraints<br />Features<br />Schedule<br />Cost<br />Value / Vision<br />Driven<br />Plan<br />Driven<br />Estimates<br />Schedule<br />Cost<br />Features<br />Source: Referenced by Michelle Sliger in “Relating PMBOK Practices to Agile Practices”<br />
  5. 5. It is Impossible to Know All Requirements in Advance<br />It is not possible to completely specify an interactive system.<br />Wegner’s Lemma, 1995<br />Uncertainty is inherent and inevitable in software development processes and products.<br />Ziv’s Uncertainty Principle, 1996<br />For a new software system the requirements will not be completely known until after the users have used it.<br />Humphrey’s Requirements Uncertainty Principle<br />
  6. 6. What Emerges?<br />It is impossible to know all requirements in advance<br />“Thinking harder” and “thinking longer” can uncover some requirements, but<br />Emergent requirements are those our users cannot identify in advance<br />Every project has some emergent requirements<br />
  7. 7. Features / Functions Used in a Typical System<br /><ul><li>The biggest cost of Predictive Development is overproduction of features
  8. 8. Must be designed, built, and maintained
  9. 9. Don’t get used; provide no value</li></ul>*Standish Group Study Reported in 2000 Chaos Report.<br />Don’t Build What Won’t Be Used<br />
  10. 10. What is Product Ownership?<br />Agile View of Product Management<br />Identify partial concepts<br />Assess<br />Source: “User Stories Applied” and “Agile Estimating and Planning,” by Mike Cohn<br />
  11. 11. Core Vision<br />Business Drives Development<br /><ul><li>Scrum considers this a good thing.
  12. 12. Builds a closer relationship between business and technologists.
  13. 13. Maintaining a healthy backlog is key to supporting business needs.</li></li></ul><li>Product Backlog: Characteristics<br />
  14. 14. Challenges to Healthy Backlog<br />Multiple lists of work<br />Bugs to fix<br />Product Features<br />Unfinished Product<br />Technical Backlog<br />
  15. 15. Challenges: Multiple Backlogs<br /><ul><li>Create a single prioritized list of work:The Product Backlog</li></ul>Potentially-Shippable Product Increment<br />Product Backlog<br />
  16. 16. Challenges: Multiple backlogs<br />Single prioritized list<br />Product Owner<br />Sales<br />“Bugs List”<br />Biz Analysts<br />Etc…<br />Stakeholders<br />Architect<br />IT Ops<br />Product Features<br />Customer Service<br />Product Definition Group<br />Product Backlog<br />Technical Backlog<br />
  17. 17. Challenges to healthy backlog<br />No stack-ranked prioritized list<br />Possible Causes:<br /><ul><li>Cannot compare priority for
  18. 18. Cannot get agreement on priority order</li></ul>Features<br />Bugs<br />Technical Items<br />VS<br />VS<br />
  19. 19. Challenges: Relative Priority<br />As a &lt;&lt;user&gt;&gt;<br />I want to &lt;&lt;goal&gt;&gt;<br />so that I can know when to expect my package<br />As a &lt;&lt;user&gt;&gt;<br />I want to &lt;&lt;goal&gt;&gt;<br />so that customer service receives 20 fewer calls each day<br />As a &lt;&lt;user&gt;&gt;<br />I want to &lt;&lt;goal&gt;&gt;<br />so that 10K concurrent user requests are handled <br /><ul><li>Cannot compare priority for </li></ul> Express each item in terms of business value; aka User Story<br />Features<br />Technical Items<br />Bugs<br />VS<br />VS<br />
  20. 20. Source: “User Stories Applied” and “Agile Estimating and Planning,” by Mike Cohn<br />Challenges: Relative Priority<br />Factors in Prioritization<br />Business value<br />Primary determinant<br />Ask “how much would this benefit the business,” or “how much bang for my buck?”<br />…don’t overlook a few other factors<br />Risk reduction<br />Change in relative cost<br />Learning / uncertainty<br />Where these come into play, items on the Product Backlog may need a boost in priority<br />
  21. 21. Dot Voting Technique <br />Place all User Story cards on a wall<br />Give 4 to 5 sticky dots to each participant<br />Ask each participant to vote for their highest priority items. Each person can place more than one dot on a single item.<br />Dotted cards have higher priority than non-dotted cards, move them to separate wall.<br />Order backlog with most number of dots to least (1st Pass)<br />Go to 2 – Until all items are prioritized<br />Relative Priority: Getting Agreement<br />1st Pass<br />Lower Priority<br />Highest Priority<br />
  22. 22. Product Owner Owns Product Backlog<br />“Collectively, the developers have a sequence in which they would like to implement the features, <br />as will the customer. <br />When there is a disagreement to the sequence, <br />the customer wins. Every time.<br />However, customers cannot prioritize without some information from the development team, it is up to the development team to provide information (assumptions, constraints, alternatives) to the customer in order to help her prioritize the features.”<br />Mike Cohn, User Stories Applied<br />Source: “User Stories Applied” by Mike Cohn<br />
  23. 23. Challenges to Healthy Backlog<br />Possible Causes<br />Bugs or unfinished tasks during sprint<br />Over-specification<br />Too many backlog items<br />
  24. 24. Challenges: Bugs/Unfinished Tasks<br />As a &lt;&lt;user&gt;&gt;<br />I want to &lt;&lt;goal&gt;&gt;<br />so that I can know when to expect my package<br />If part of a story is not done, then the entire story is not done<br />Re-prioritize entire story<br />Product Backlog<br />Add bugs and incomplete tasks<br />
  25. 25. Challenges: Over Specification<br />Converting requirements docs/use cases into backlog items line-for-line makes a very large backlog. <br />Impossible to specify a system in its entirety.<br />
  26. 26. Challenges: Over Specification<br />Business Analyst’s Job<br />Traditional<br />Agile<br />Create Understanding<br />Create Documents<br />
  27. 27. Challenges: Over Specification<br />Game of asteroids <br />http://www.agileiq.org/2009/05/29/asteroids/<br />
  28. 28. Challenges to Healthy Backlog<br />Backlog not ready for team<br />Possible Causes<br />Difficulty splitting larger user stories<br />Not enough information to begin development<br />
  29. 29. User Story Splitting “Smells”<br />Split along process lines<br />Design, code, test, document<br />Split across architecture lines<br />Database, Business Tier, UI<br />“Big picture” of the original story is lost<br />Individual stories no longer have clear customer value<br />
  30. 30. How to Split Stories<br />Data boundaries<br />Just show the record ID, don’t link systems yet<br />Operational boundaries<br />Implement “Read”, then “Create/Delete”<br />Exceptions and Error handling<br />Do the “happy path” first<br />Removing cross-cutting concerns<br />Establish end-to-end with dummy data<br />Stub out complexity<br />
  31. 31. Special-Purpose Story Types<br />SPIKE<br /><ul><li>A quick and dirty implementation, designed to be thrown away, to gain knowledge
  32. 32. Indicator: Unable to estimate a user story effectively</li></ul>RESEARCH<br /><ul><li>Broad, foundational knowledge-gaining to decide what to spike or to give the ability to estimate
  33. 33. Indicator: Don’t know a potential solution</li></ul>TRACER BULLET<br /><ul><li>Narrow implementation in production quality of an epic/large user story
  34. 34. Indicator: User story is too large, hard to estimate</li></li></ul><li>Challenges: Not Enough Information<br />Need clear acceptance criteria<br />Objectively determine – Have we built the right thing?<br />Need to be sufficient to test the feature<br />Backlog grooming is key<br />Team has a chance to ask questions<br />Makes differing assumptions visible<br />Give Product Owner pre-planning feedback<br />Time to clarify stories<br />Protects prioritization by customer value<br />
  35. 35. Grooming for Backlog Readiness<br />Product Backlog items must be understandable by both the team and the Product Owner<br />Team invests 5-10% of their capacity working with the Product Owner to prepare for the next Sprint<br />A suggested approach<br />Meet about 2-days before end of Sprint<br />PO has about 1.5x the number of stack-ranked stories<br />Acceptance Criteria are adjusted and agreed on<br />Team estimates<br />Split stories<br />Re-Prioritize<br />
  36. 36. Summary: Healthy Backlog<br />Have a single product backlog<br />Stack-ranked prioritized list<br />Use User Stories to compare by business value<br />Product Owner has final say on priority<br />Keep the Product Backlog reasonably sized<br />Put unfinished Stories back on the backlog<br />Don’t over-specify low-priority items<br />Groom the backlog before Sprint Planning<br />Split large user stories along business value lines<br />Stories must have acceptance criteria<br />
  37. 37. Founded: 1979<br />Employees: 250+<br />Headquarters: Redmond, WA<br />Full range of technology consulting services, from Agile training and consulting to software development and talent acquisition <br />Leading provider of Scrum Certification Training<br />
  38. 38. Agile Services at Every Stage<br />
  39. 39. Questions & Answers<br />
  40. 40. Upcoming SolutionsIQ Webinars Presented by VersionOne<br />Soon AgilePortfolio Metrics: A Dashboard for Executives<br />Soon Strategies for Maximizing Agile Portfolio Value<br />
  41. 41. Thank You<br />Following this presentation, participants will receive an email with links to a recording and copies of today’s slides<br />For more on SolutionsIQ<br />www.SolutionsIQ.com<br />info@SolutionsIQ.com<br />+1(800)235-4091<br />