Name: Product Backlog Problem: You can't do everything at once, and you want to optimize ROI Solution: Make a list of deliverables ordered by delivery date Author: Jim Coplien Name: Product Owner Problem: You can't do everything at once, and you want to optimize ROI Solution: Make a list of deliverables ordered by delivery date Author: Jim Coplien Name: Fixed Work Problem: Some work must be done on the team, but is difficult to estimate a closed work item Solution: Compartmentalize both recurring work and occasional spikes of work, particularly those that support the Product Owner process instead of directly building potentially shippable product Author: Jim Coplie Name: Product Backlog Items Problem: You want a list that drives ROI, including effects from cost, but which also develops empathy from the market Solution: Create backlog items as deliverables that can be demonstrated to relevant stakeholders Author: Jim Coplien Name: Estimation Points Problem: If you spend a lot of effort estimating in days or hours, and your velocity changes, then the estimates are all wrong. Solution: Use unit-less numbers for effort estimation. Author: Jim Coplien Name: ROI Problem: Scrum commonly says to order the Product Backlog by priority — but, by whose priority, and why? Solution: Order the product backlog so as to give the highest ROI in the long term. Author: Jim Coplien Name: High Value First Problem: You are a customer on an agile project and you are involved in the Planning Game. You are trying to decide which stories to schedule in the next few iterations or sprints. Solution: Build the high value, most essential, PBIs first. Author: Joseph Bergin Name: Change for Free Problem: Some PBIs are context-free, and you want to respond to customer changes under High Value First while ever increasing the ROI Solution: Exchange emergent requirements for existing PBIs of equal cost if their ROI is higher Author: Jim Coplien Name: Money for Nothing Problem: If you deliver High Value First you will eventually come to a point of diminishing returns Solution: Stop development when the cost of continuing exceeds the benefit that the enterprise will receive from the development Author: Jim Coplien Name: Enabling Specification Problem: Unexplored requirements cause unpleasant surprises Solution: The Product Owner should deliver enabling specifications as a sign that he or she has done due diligence in exploring the requirements space Author: Jim Coplien Name: Small Items to Estimate Problem: Estimates are inaccurate Solution: If you have problem with inaccurate estimates, then make the tasks smaller to reduce uncertainty in estimation. Local precision improves overall accuracy Author: Jim Coplien Name: Granularity Gradient Problem: Small items are easiest to estimate, but breaking down deliverables and work items is a lot of work in itself. Solution: The earliest PBIs are broken down to half a sprint or less of work for an individual, the later ones may be epics, with the in-between ones broken down in accordance with how distant their release date is. Author: Jim Coplien Name: Estimation Range Problem: Solution: If you want a better picture of your risk, then estimate best-case, expected case and worst-case results. Author: Jim Coplien Name: Project Management Problem: You have several revenue streams but the work is sparse enough that none of them alone is enough to keep a single Scrum team busy. Solution: If you need to run several different revenue streams (projects), but have a single project, then add version streams to facilitate that. Author: Jim Coplien Name: Refactor PBIs Name: Bop the Mole Problem: You commonly find that PBIs are 90% complete at the end of a sprint. They're not DONE and so can't be delivered. Solution: Burn down all the tasks of a PBI together. Author: Jim Coplien Name: Domino Effect Problem: Blah Solution: Blah Author: Jim Coplien Name: Unordered Sprint Backlog Problem: You find that the team frequently misses its Sprint commitment, and you want to optimize ROI by honoring the Product Owner's ordering of PBIs Solution: Avoid the temptation to order the Sprint backlog, but instead do process improvement so the team regularlly makes its commitment Author: Jim Coplien Name: Aggregate Velocity Problem: You can't compare velocities between teams, but some PBIs require work from multiple teams, and the Product Backlog estimate should help set the right expectations about commitments. Solution: Use Estimation Points with respect to collective notion of velocity that reflects the pace of the entire collection of staff working on the Product Backlog. Author: Jim Coplien Name: Specialized Velocities Problem: You can't compare velocities between teams, but some PBIs require work from multiple teams, and the Product Backlog estimate should help set the right expectations about commitments. Solution: If you have specialized teams, let each team estimate the PBIs within its area of specialization. Author: Jim Coplien Name: Yesterday's Weather Problem: You are trying to estimate a task Solution: Assume the same work pace as yesterday, or as in the past Author: Jim Coplien Name: Sacred Schedule Problem: Solution: Don't ever extend the length of a sprint. Author: Joseph Bergin Name: Updated Velocity Problem: You want the velocity to reflect the team's current abilities, yet it takes time to know whether process improvements actually worked Solution: Update the velocity only if a new level is sustained for the past three sprints. Author: Jim Coplien Name: Pigs Estimate Problem: Solution: Author: Jim Coplien Name: Sprint Planning Meeting Problem: Solution: (Needs URL update once draft structure is in place) Author: Jim Coplien |
Very Old Patterns >