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: The financial value of having the features The cost of developing (and perhaps supporting) the new features The amount and significance of learning and new knowledge created by developing the features Knowledge about the product Knowledge about the project 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 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.