Notes from Agile Estimating and Planning Works by Mike Cohn

Notes from Agile Estimating and Planning Works by Mike Cohn

Purpose of the book - Agile approach to estimating and planning.


Part 1: The Problem and the Goal

** Important to understand purpose of planning

“Planning is everything. Plans are nothing.”

—Field Marshal Helmuth Graf von Moltke

Plans guide our investment decisions. e.g. If a project takes 6 months and cost 1 mil we might accept it compare to 2yrs and 4 mil.

Plans outlines resource needed, track to deliverables. Without plan projects go through any number of problems

Yet planning is difficult and often plans are wrong
Two extremes - No plan or over plan and over confidence.

Without a plan cannot answer basic questions (when will the work be done)
Over plan -

Plan are off 60 - 160%
i.e. 20 weeks estimate means 17-23 weeks

Planning is to find optimal solution

Why plan then if its difficult?
A good plan supports - reduce risk, uncertainty, better decision, trust and info

Plans iterate. If no one comes with a better idea later it fails.

good plan? - reliable for making decisions

Agile planning - willing to change

Planning is more imp than plan **

** Estimates given early are less accurate than given later.

1.	This chapter started by making the claim that overplanning and doing no planning are equally dangerous. What is the right amount of planning on your current project?
2.	What other reasons can you think of for planning?
3.	Think of one or two of the most successful projects in which you have been involved. What role did planning play in those projects?

** Nearly two-thirds of projects significantly overrun their cost estimates (Lederer and Prasad 1992)
** 64% of the features included are rarely or never used (Johnson 2002)
** The avg project exceeds its schedule by 100% (Standish 2001)

Why planning fails?
1. Planning is by activity rather than feature
2. Multi tasking
3. Priority
4. Ignoring uncertainty
5. Estimates becomes commitments

Discussion Questions

1.	What problems result from plans being based on activities rather than deliverable features?
2.	In your current environment, is an estimate the same as a commitment? What problems does this cause? What could you do to change this misperception?
3.	In what ways does multitasking affect your current project? How could you reduce that impact?

“A good plan violently executed now is better than a perfect plan executed next week.”

—General George S. Patton

Authors of Agile Manifesto values
1. Individuals and interactions over process and tools
2. Working software over doc
3. Customer collab over negotations
4. Responding to change over plan

Agile approach to projects
1. Work as one team
2. Work in short iterations
3. Deliver something each iteration
4. Focus on business priorities
5. Inspect and adapt


Agile approach to planning
The planning onion. Agile teams plan at least at the release, iteration, and day levels.

1.	How would working as a unified whole team have affected your current or last project?
2.	What are the conditions of satisfaction on your current project? Do all project stakeholders and participants agree on all of them? What risks are there to proceeding on a project that does not have agreement on all conditions of satisfaction?
3.	Why are budget and schedule listed in Figure 3.2 as conditions of satisfaction to be considered during release planning but not during iteration planning?

Part 2: Estimating Size

Estimate

Separate estimate of size from duration
Story points are relative - define a small unit of work and use it as metric
Velocity
Ideal time is not equal to elapsed time - (Since ppl take sick time, meetings etc)
Almost estimate on ideal time.
Not a good idea to divide estimates based on skills or area
Estimates are done by all irrespective who works on it

Estimate stories using fibonacci 1, 2, 3, 5, 8, small stories are ok to count as 0.
Epics and Themes constitute 13, 20, 40, 100 sizes.



Estimate technique
1. Ask the expert.
2. Analogy (Relative)
3. Disaggregate (split)

Planning poker.

Velocity is a great equalizer

When to reestimate - after learning one of the similar story has drifted
What to do?
No reestimate
Switch the velocity
re-estimate with new size

re-estimating partially completed stories

Story points vs Ideal days -- Prefer story points

Part 3: Planning for Value
Prioritize --> value, cost, new knowledge, risk

“The indispensable first step to getting what you want is this: Decide what you want.”

—Ben Stein

e.g. building security framework into app --> value not much, cost low initially high later, new knowledge none, risk high coz it adds no value to the product success.
e.g. 2 --> user interface, value much, cost low initially, knowledge yes, risk low coz it adds lot of value.

Financial prioritization

“As a general rule of thumb, when benefits are not quantified at all, assume there aren’t any.”

—Tom DeMarco and Timothy Lister

Some projects are done for generating revenue some to cut cost, if we can estimate we can plan accordingly.

Source of return
1. new revenue
2. incremental revenue
3. retained revenue
4. operational efficiencies

Prioritization Desirability

“If you have a choice of two things and can’t decide, take both.”

—Gregory Corso

when to split story - when it doesn't fit in iteration or smaller stories will allow accurate estimates.

How to split stories?
1. around data boundaries
2. operation boundaries
3. cross cutting concerns
4. performance
5. don't split on tasks
6. avoid temptation of related changes

Part 4 : Scheduling

Release planning - covers longer period than iteration.
It tells how much to develop and how long
acts as guide post

Part 5: Tracking and Communicating

Part 6: Why Agile Planning Works