Mike Cohn - Agile Estimating and
Planning
Why Planning fails
• Planning Is By Activity Rather Than Feature
– Activities Don’t Finish Early
– Lateness Is Passed Down the Schedule
– Activities Are Not Independent
•
•
•
•
Multitasking Causes Further Delays
Features Are Not Developed By Priority
We Ignore Uncertainty
Estimates Become Commitments
Agile Planning
•
•
•
•
Is focused more on the planning than the plan
Encourages change
Results in plans that are easily changed
Is spread throughout the project
Agile Approach
•
•
•
•
•
Work as one team
Work in short iterations
Deliver something each iteration
Focus on business priorities
Inspect and adapt
The planning onion
Known Stuff
•
•
•
•
•
Chapter 4: Estimating Size with Story Points
Chapter 5: Estimating In Ideal Days
Chapter 6: Techniques for Estimating
Chapter 7: Re-Estimating
Chapter 8: Choosing Between Story Points and
Ideal Days
Prioritizing Themes
Factors In Prioritization:
1. The financial value of having the features
2. The cost of developing (and perhaps supporting) the
new features
3. The amount and significance of learning and new
knowledge created by developing the features
– Knowledge about the product
– Knowledge about the project
4. The amount of risk removed by developing the
features
Reducing uncertainty
Combining risk and value
Financial Prioritization
•
•
•
•
Net Present Value
Internal Rate of Return
Payback period
Discounted payback period
Prioritizing Desirability
Kano Model of Customer Satisfaction:
• Threshold, or must-have, features
• Linear features
• Exciters and delighters
Kano Model
Assessing Themes On The Kano Model
Categorizing a Feature
Splitting User Stories
• Split large stories along the boundaries of the data supported by the story.
• Split large stories based on the operations that are performed within the
story.
• Split large stories into separate CRUD operations.
• Consider removing cross-cutting concerns (such as security, logging, error
handling, and so on) and creating two versions of the story: one with and
one without support for the cross-cutting concern.
• Considering splitting a large story by separating the functional and
nonfunctional aspects into separate stories (* Performance constraints)
• Separate a large story into smaller stories if the priorities of the smaller
• stories are different.
• Don’t split a large story into tasks. Instead, try to find a way to fire a tracer
bullet through the story.
• Avoid making things worse by adding related changes to an appropriately
sized feature, unless the related changes are of equivalent priority.
Release Planning
Conditions of Satisfaction
• Date-driven
OR (!)
• Feature-driven
Plan Detalization
Page 135, topic for discussion
The next question to be addressed regards how
detailed the release plan will be. Some teams in
some environments prefer to create a release plan
that shows what they expect to develop during each
iteration. Other teams prefer simply to determine
what they think will be developed during the overall
release, leaving the specifics of each iteration for
later. This is something to be discussed and decided
during release planning.
Iteration Planning: Velocity Driven
• Tasks Are Not Allocated During Iteration
Planning
• Estimate Tasks
– Task estimating on an agile project should be a
group endeavor
• Meetings Count (A Lot)
– Report US-related meeting time to US tasks
Iteration Planning: Commitment
Driven
Selecting An Iteration Length
• The length of the release being worked on
– 4-5 iterations
•
•
•
•
•
•
The amount of uncertainty
The ease of getting feedback
How long priorities can remain unchanged
Willingness to go without feedback
The overhead of iterating
A feeling of urgency is maintained
Buffering Plans for Uncertainty
• Feature Buffers
– 30% of optional features
• Schedule Buffers
Planning the Multi-Team Project
1.
2.
3.
4.
Establishing a common basis for estimates
Adding detail to their user stories sooner
Lookahead planning
Incorporating feeding buffers into the plan
Monitoring The Plan
• Monitoring The Release Plan
– Release Burndown Chart
• Monitoring The Iteration Plan
– Task Board
– Teams should be reluctant to track the actual
hours expended on tasks in order to get better at
estimating. The risks and the effort to do so
usually outweigh the benefits.
Why Agile Planning Works
•
•
•
•
•
•
•
•
Re-planning Occurs Frequently
Estimates Of Size and Duration Are Separated
Plans Are Made At Different Levels
Plans Are Based On Features, Not Tasks
Small Stories Keep Work Flowing
Work In Process Is Eliminated Every Iteration
Tracking Is At The Team Level
Uncertainty Is Acknowledged And Planned For
A Dozen Guidelines for Agile
Estimating and Planning
• Involve the whole team.
• Plan at different levels.
• Keep estimates of size and duration separate by using different
units.
• Express uncertainty in either the functionality or the date.
• Replan often.
• Track and communicate progress.
• Acknowledge the importance of learning.
• Plan features of the right size.
• Prioritize features.
• Base estimates and plans on facts.
• Leave some slack.
• Coordinate teams through lookahead planning.