Your SlideShare is downloading. ×

Keeping Product Backlog Healthy


Published on

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 …

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?

Published in: Business, Lifestyle, Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • “Data boundaries” – if you’re trying to pull data in from a second system, where the data is associated by a record number, don’t try to make the data show up in your product for the first release. Just show the record number, which the human user can then enter into the second system to retrieve the data. Now you have:Proof that you can retrieve the correct recordActual business value, because the user can more easily find the desired recordA natural upgrade path for the feature in a future release.
  • Transcript

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