Dhaval Panchal discusses the importance of maintaining a healthy product backlog in agile project management, emphasizing the need for a single prioritized list to align business objectives and development efforts. He highlights challenges such as over-specification, difficulty in prioritizing, and incomplete tasks, advocating for techniques like dot voting and user story splitting to enhance backlog readiness and clarity. Key practices include ensuring acceptance criteria, involving the product owner in prioritization, and conducting regular backlog grooming sessions to remain responsive to business needs.

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