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
Problem: Too many small PBIs deep in the Product Backlog
Solution: If PBIs become less important, aggregate them as they move down the product backlog.
Author: Jim Coplien
Name: Bop the Mole
Problem: A separate bug tracking system leaves an increasing inventory of bugs
Solution: You don't want to keep an inventory of bugs; therefore, fix bugs when they arise, and avoid the use of bug-tracking systems. Large problems go on the Product Backlog.
Author: Jim Coplien
Name: Track Done
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