1. Mike Cohn - Agile Estimating and Planning

2. 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

3. 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

4. Agile Approach Work as one team Work in short iterations
Deliver something each iteration
Focus on business priorities
Inspect and adapt

5. The planning onion

6. 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

7. 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

8. Reducing uncertainty

9. Combining risk and value

10. Financial Prioritization
Net Present Value
Internal Rate of Return
Payback period
Discounted payback period

11. Prioritizing Desirability
Kano Model of Customer Satisfaction:
Threshold, or must-have, features
Linear features
Exciters and delighters

12. Kano Model

13. Assessing Themes On The Kano Model

14. Categorizing a Feature

15. 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.

16. Release Planning

17. Conditions of Satisfaction
Date-driven
OR (!)
Feature-driven

18. 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.

19. 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

20. Iteration Planning: Commitment Driven

21. 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

22. Buffering Plans for Uncertainty
Feature Buffers
30% of optional features
Schedule Buffers

23. 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

24. 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.

25. 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

26. 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.