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?
8447779800, Low rate Call girls in Uttam Nagar Delhi NCR
Â
Keeping Product Backlog Healthy
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(http://dhavalpanchal.gettingagile.com/) Received his B.S. in Engineering University of Mumbai, India
4. Project Vision Drives the Features Waterfall Agile The Plan creates cost/schedule estimates The Vision creates feature estimates Constraints Features Schedule Cost Value / Vision Driven Plan Driven Estimates Schedule Cost Features 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
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 Assess Source: “User Stories Applied” and “Agile Estimating and Planning,” by Mike Cohn
11.
12. Builds a closer relationship between business and technologists.
13.
14. Challenges to Healthy Backlog Multiple lists of work Bugs to fix Product Features Unfinished Product Technical Backlog
15.
16. Challenges: Multiple backlogs Single prioritized list Product Owner Sales “Bugs List” Biz Analysts Etc… Stakeholders Architect IT Ops Product Features Customer Service Product Definition Group Product Backlog Technical Backlog
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 Over-specification 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.
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.
32.
33.
34.
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 Re-Prioritize
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
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 www.SolutionsIQ.com info@SolutionsIQ.com +1(800)235-4091
Editor's Notes
“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.