Skip to main content

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


Separate estimate of size from duration
Story points are relative - define a small unit of work and use it as metric
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


Benjamin Cain said…
Some of the productivity designers who are superb at their job they actually knows how things can be better through the help of improvement and at the same time they do have ways for growing into the correct direction and you can get to understand ways for it because finally this is the way how it works. agile technology is a plus with it because it takes all to another level.

Popular posts from this blog

JPA 2 new feature @ElementCollection explained

@ElementCollection is new annotation introduced in JPA 2.0, This will help us get rid of One-Many and Many-One shitty syntax.

Example 1: Stores list of Strings in an Entity

public class Users implements Serializable {

    private static final long serialVersionUID = 1L;
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private List<String> certifications = new ArrayList<String>();

    public Long getId() {
        return id;

    public void setId(Long id) { = id;

    public List<String> getCertifications() {
        return certifications;

    public void setCertifications(List<String> certifications) {
        this.certifications = certifications;

        Users u = new Users();
        u.getCertifications().add("Sun Certified Java Programmer");

Generated Tables

Column --> ID
    Row             1


Validating CSV Files

What is CsvValidator ?
  A Java framework which validates any CSV files something similar to XML validation using XSD.

Why should I use this ?
  You don't have to use this and in fact its easy to write something your own and also checkout its source code for reference.

Why did I write this ?
  Some of our projects integrate with third party application which exchanges information in CSV files so I thought of writing a generic validator which can be hooked in multiple projects or can be used by QA for integration testing.

What is the license clause ?

Are there any JUnit test cases for me checkout ?
 Yes, source

How to integrate in my existing project ?

Just add the Jar which can be downloaded from here CsvValidator.jar and you are good.

Instantiate CsvValidator constructor which takes these 3 arguements

         // filename is the the file to be validated and here is a sample         // list - defines all the fields in the above csv file ( a field has index, type, isOptional, rege…