Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Keeping Product Backlog Healthy

•
•
Dhaval Panchal
Dhaval Panchal

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?

Related slideshows

Value Stream Management: Is Your Organization Ready?
Value Stream Management: Is Your Organization Ready?Value Stream Management: Is Your Organization Ready?
Value Stream Management: Is Your Organization Ready?
 
User Story Sizing using Agile Relative Estimation
User Story Sizing using Agile Relative EstimationUser Story Sizing using Agile Relative Estimation
User Story Sizing using Agile Relative Estimation
 
Agile Scrum Estimation
Agile Scrum EstimationAgile Scrum Estimation
Agile Scrum Estimation
 
1 of 35
Keeping a Healthy Product BacklogDhaval Panchal, CST and Agile Coach
Dhaval PanchalCertified Scrum Trainer (CST) and Agile coach Consults with organizations from mid-sized product companies to the Fortune 100Experience in software development, business and functional analysis, Lean office implementations, organizational change, system architecture, business intelligence, and project managementWrites about software development and coaching on his blog(http://dhavalpanchal.gettingagile.com/)Received his B.S. in Engineering University of Mumbai, India
Product Backlog: Point of ViewMaximize ROIManage RiskBalance WorkloadEnhance Value
Project Vision Drives the FeaturesWaterfallAgileThe Plan createscost/schedule estimatesThe Vision createsfeature estimatesConstraintsFeaturesScheduleCostValue / VisionDrivenPlanDrivenEstimatesScheduleCostFeaturesSource: Referenced by Michelle Sliger in “Relating PMBOK Practices to Agile Practices”
It is Impossible to Know All Requirements in AdvanceIt is not possible to completely specify an interactive system.Wegner’s Lemma, 1995Uncertainty is inherent and inevitable in software development processes and products.Ziv’s Uncertainty Principle, 1996For a new software system the requirements will not be completely known until after the users have used it.Humphrey’s Requirements Uncertainty Principle
What Emerges?It is impossible to know all requirements in advance“Thinking harder” and “thinking longer” can uncover some requirements, butEmergent requirements are those our users cannot identify in advanceEvery project has some emergent requirements
Features / Functions Used in a Typical SystemThe biggest cost of Predictive Development is overproduction of features
Must be designed, built, and maintained
Don’t get used; provide no value*Standish Group Study Reported in 2000 Chaos Report.Don’t Build What Won’t Be Used
What is Product Ownership?Agile View of Product ManagementIdentify partial conceptsAssessSource: “User Stories Applied” and “Agile Estimating and Planning,” by Mike Cohn
Core VisionBusiness Drives DevelopmentScrum considers this a good thing.
Builds a closer relationship between business and technologists.
Maintaining a healthy backlog is key to supporting business needs.Product Backlog: Characteristics
Challenges to Healthy BacklogMultiple lists of workBugs to fixProduct FeaturesUnfinished ProductTechnical Backlog
Challenges: Multiple BacklogsCreate a single prioritized list of work:The Product BacklogPotentially-Shippable Product IncrementProduct Backlog
Challenges: Multiple backlogsSingle prioritized listProduct OwnerSales“Bugs List”Biz AnalystsEtc…StakeholdersArchitectIT OpsProduct FeaturesCustomer ServiceProduct Definition GroupProduct BacklogTechnical Backlog
Challenges to healthy backlogNo stack-ranked prioritized listPossible Causes:Cannot compare priority for
Cannot get agreement on priority orderFeaturesBugsTechnical ItemsVSVS
Challenges: Relative PriorityAs a <<user>>I want to <<goal>>so that I can know when to expect my packageAs a <<user>>I want to <<goal>>so that customer service receives 20 fewer calls each dayAs 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 StoryFeaturesTechnical ItemsBugsVSVS
Source: “User Stories Applied” and “Agile Estimating and Planning,” by Mike CohnChallenges: Relative PriorityFactors in PrioritizationBusiness valuePrimary determinantAsk “how much would this benefit the business,” or “how much bang for my buck?”…don’t overlook a few other factorsRisk reductionChange in relative costLearning / uncertaintyWhere these come into play, items on the Product Backlog may need a boost in priority
Dot Voting Technique Place all User Story cards on a wallGive 4 to 5 sticky dots to each participantAsk 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 prioritizedRelative Priority: Getting Agreement1st PassLower PriorityHighest Priority
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 AppliedSource: “User Stories Applied” by Mike Cohn
Challenges to Healthy BacklogPossible CausesBugs or unfinished tasks during sprintOver-specificationToo many backlog items
Challenges: Bugs/Unfinished TasksAs a <<user>>I want to <<goal>>so that I can know when to expect my packageIf part of a story is not done, then the entire story is not doneRe-prioritize entire storyProduct BacklogAdd bugs and incomplete tasks
Challenges: Over SpecificationConverting requirements docs/use cases into backlog items line-for-line makes a very large backlog. Impossible to specify a system in its entirety.
Challenges: Over SpecificationBusiness Analyst’s JobTraditionalAgileCreate UnderstandingCreate Documents
Challenges: Over SpecificationGame of asteroids http://www.agileiq.org/2009/05/29/asteroids/
Challenges to Healthy BacklogBacklog not ready for teamPossible CausesDifficulty splitting larger user storiesNot enough information to begin development
User Story Splitting “Smells”Split along process linesDesign, code, test, documentSplit across architecture linesDatabase, Business Tier, UI“Big picture” of the original story is lostIndividual stories no longer have clear customer value
How to Split StoriesData boundariesJust show the record ID, don’t link systems yetOperational boundariesImplement “Read”, then “Create/Delete”Exceptions and Error handlingDo the “happy path” firstRemoving cross-cutting concernsEstablish end-to-end with dummy dataStub out complexity
Special-Purpose Story TypesSPIKEA quick and dirty implementation, designed to be thrown away, to gain knowledge
Indicator: Unable to estimate a user story effectivelyRESEARCHBroad, foundational knowledge-gaining to decide what to spike or to give the ability to estimate
Indicator: Don’t know a potential solutionTRACER BULLETNarrow implementation in production quality of an epic/large user story
Indicator: User story is too large, hard to estimateChallenges: Not Enough InformationNeed clear acceptance criteriaObjectively determine – Have we built the right thing?Need to be sufficient to test the featureBacklog grooming is keyTeam has a chance to ask questionsMakes differing assumptions visibleGive Product Owner pre-planning feedbackTime to clarify storiesProtects prioritization by customer value
Grooming for Backlog ReadinessProduct Backlog items must be understandable by both the team and the Product OwnerTeam invests 5-10% of their capacity working with the Product Owner to prepare for the next SprintA suggested approachMeet about 2-days before end of SprintPO has about 1.5x the number of stack-ranked storiesAcceptance Criteria are adjusted and agreed onTeam estimatesSplit storiesRe-Prioritize

More Related Content

Keeping Product Backlog Healthy

  • 1. Keeping a Healthy Product BacklogDhaval Panchal, CST and Agile Coach
  • 2. Dhaval PanchalCertified Scrum Trainer (CST) and Agile coach Consults with organizations from mid-sized product companies to the Fortune 100Experience in software development, business and functional analysis, Lean office implementations, organizational change, system architecture, business intelligence, and project managementWrites about software development and coaching on his blog(http://dhavalpanchal.gettingagile.com/)Received his B.S. in Engineering University of Mumbai, India
  • 3. Product Backlog: Point of ViewMaximize ROIManage RiskBalance WorkloadEnhance Value
  • 4. Project Vision Drives the FeaturesWaterfallAgileThe Plan createscost/schedule estimatesThe Vision createsfeature estimatesConstraintsFeaturesScheduleCostValue / VisionDrivenPlanDrivenEstimatesScheduleCostFeaturesSource: Referenced by Michelle Sliger in “Relating PMBOK Practices to Agile Practices”
  • 5. It is Impossible to Know All Requirements in AdvanceIt is not possible to completely specify an interactive system.Wegner’s Lemma, 1995Uncertainty is inherent and inevitable in software development processes and products.Ziv’s Uncertainty Principle, 1996For 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, butEmergent requirements are those our users cannot identify in advanceEvery project has some emergent requirements
  • 7. Features / Functions Used in a Typical SystemThe 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 ManagementIdentify partial conceptsAssessSource: “User Stories Applied” and “Agile Estimating and Planning,” by Mike Cohn
  • 11. Core VisionBusiness Drives DevelopmentScrum 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 BacklogMultiple lists of workBugs to fixProduct FeaturesUnfinished ProductTechnical Backlog
  • 15. Challenges: Multiple BacklogsCreate a single prioritized list of work:The Product BacklogPotentially-Shippable Product IncrementProduct Backlog
  • 16. Challenges: Multiple backlogsSingle prioritized listProduct OwnerSales“Bugs List”Biz AnalystsEtc…StakeholdersArchitectIT OpsProduct FeaturesCustomer ServiceProduct Definition GroupProduct BacklogTechnical Backlog
  • 17. Challenges to healthy backlogNo stack-ranked prioritized listPossible Causes:Cannot compare priority for
  • 18. Cannot get agreement on priority orderFeaturesBugsTechnical ItemsVSVS
  • 19. Challenges: Relative PriorityAs a <<user>>I want to <<goal>>so that I can know when to expect my packageAs a <<user>>I want to <<goal>>so that customer service receives 20 fewer calls each dayAs 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 StoryFeaturesTechnical ItemsBugsVSVS
  • 20. Source: “User Stories Applied” and “Agile Estimating and Planning,” by Mike CohnChallenges: Relative PriorityFactors in PrioritizationBusiness valuePrimary determinantAsk “how much would this benefit the business,” or “how much bang for my buck?”…don’t overlook a few other factorsRisk reductionChange in relative costLearning / uncertaintyWhere 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 wallGive 4 to 5 sticky dots to each participantAsk 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 prioritizedRelative Priority: Getting Agreement1st PassLower PriorityHighest 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 AppliedSource: “User Stories Applied” by Mike Cohn
  • 23. Challenges to Healthy BacklogPossible CausesBugs or unfinished tasks during sprintOver-specificationToo many backlog items
  • 24. Challenges: Bugs/Unfinished TasksAs a <<user>>I want to <<goal>>so that I can know when to expect my packageIf part of a story is not done, then the entire story is not doneRe-prioritize entire storyProduct BacklogAdd bugs and incomplete tasks
  • 25. Challenges: Over SpecificationConverting 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 SpecificationBusiness Analyst’s JobTraditionalAgileCreate UnderstandingCreate Documents
  • 27. Challenges: Over SpecificationGame of asteroids http://www.agileiq.org/2009/05/29/asteroids/
  • 28. Challenges to Healthy BacklogBacklog not ready for teamPossible CausesDifficulty splitting larger user storiesNot enough information to begin development
  • 29. User Story Splitting “Smells”Split along process linesDesign, code, test, documentSplit across architecture linesDatabase, Business Tier, UI“Big picture” of the original story is lostIndividual stories no longer have clear customer value
  • 30. How to Split StoriesData boundariesJust show the record ID, don’t link systems yetOperational boundariesImplement “Read”, then “Create/Delete”Exceptions and Error handlingDo the “happy path” firstRemoving cross-cutting concernsEstablish end-to-end with dummy dataStub out complexity
  • 31. Special-Purpose Story TypesSPIKEA quick and dirty implementation, designed to be thrown away, to gain knowledge
  • 32. Indicator: Unable to estimate a user story effectivelyRESEARCHBroad, foundational knowledge-gaining to decide what to spike or to give the ability to estimate
  • 33. Indicator: Don’t know a potential solutionTRACER BULLETNarrow implementation in production quality of an epic/large user story
  • 34. Indicator: User story is too large, hard to estimateChallenges: Not Enough InformationNeed clear acceptance criteriaObjectively determine – Have we built the right thing?Need to be sufficient to test the featureBacklog grooming is keyTeam has a chance to ask questionsMakes differing assumptions visibleGive Product Owner pre-planning feedbackTime to clarify storiesProtects prioritization by customer value
  • 35. Grooming for Backlog ReadinessProduct Backlog items must be understandable by both the team and the Product OwnerTeam invests 5-10% of their capacity working with the Product Owner to prepare for the next SprintA suggested approachMeet about 2-days before end of SprintPO has about 1.5x the number of stack-ranked storiesAcceptance Criteria are adjusted and agreed onTeam estimatesSplit storiesRe-Prioritize
  • 36. Summary: Healthy BacklogHave a single product backlogStack-ranked prioritized listUse User Stories to compare by business valueProduct Owner has final say on priorityKeep the Product Backlog reasonably sizedPut unfinished Stories back on the backlogDon’t over-specify low-priority itemsGroom the backlog before Sprint PlanningSplit large user stories along business value linesStories must have acceptance criteria
  • 37. Founded: 1979Employees: 250+Headquarters: Redmond, WAFull 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
  • 40. Upcoming SolutionsIQ Webinars Presented by VersionOneSoon AgilePortfolio Metrics: A Dashboard for ExecutivesSoon Strategies for Maximizing Agile Portfolio Value
  • 41. Thank YouFollowing this presentation, participants will receive an email with links to a recording and copies of today’s slidesFor more on SolutionsIQwww.SolutionsIQ.cominfo@SolutionsIQ.com+1(800)235-4091

Editor's Notes

  1. “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.