Estimate Size and derive duration

Planning should enable us to do right and reliable decision making. - John Maynard

I am big proponent of doing estimation. I think it has advantages if done right. For doing it right, I personally found Mike Cohn's "Estimate Size and Derive Duration technique" very useful.

In this technique we separate the step of Estimation from the step of Deriving the Duration.

In Estimation step, we figure out the size of the work to be performed. It can be done in any unit your team prefer i.e. story points, ideal time or any other unit. Once we have the rough number for size then we estimate our pace i.e velocity or cycle time.  After having both the numbers, finally we derive the duration.

Example:

Lets say we are building a new analytics dashboard. I request my team to estimate the backlog in ideal time (Time Spend doing the work) by making three assumption.

1. It's all you work on
2. no one interrupts you
3. and everything you need is available

I request them to do a rough estimation, it does not need to be precise. Then I convert the Ideal Time into Elapse Time (Time is from start to finish of the work) by taking into account their daily meetings, their other distractions etc.

After doing my above math I try to find their pace. If the team is new to agile methodology, I prefer to wait for couple of sprints/stories to finish before guessing their pace. Otherwise I like to average the velocity or cycle time by removing the out liars.

Once I have above two units, I simply divide to derive duration.

Estimation / Pace = Duration

Hope it helps
Manisha

Task finish late more often than they finish early, why?

"Failure to plan is planning to fail"     -  Winston Churchill. 
"It is better to be roughly right than precisely wrong." - John Meynard Keynes 

Planning should enable us to take right and reliable decision. Don't get me wrong, I am not asking for precise estimation.

I strongly believe in quick and rough estimation which evolves as time pass through.

In this post, I am leaning more towards what impact, human behavior and type of work we do, make on our rough estimated number.

Student Syndrome or waiting till last responsible moment ;)

Student Syndrome, refers to waiting to start a task until the last possible moment that does not preclude on time finish. (This is human nature and very difficult to change.) Lets take same feature A example. As a developer, I thought task X should not take more than 3 days but I kept one day buffer and said 4 days.

When we think we always think like below: Work (3 days) + local Buffer (1 day)

But while executing we feel very optimistic to finish the task in 3 days and we start with cleaning technical debt, preparing some flow for project or documents etc.

We behave reverse i.e. Local Buffer (1 day) + Work ( 3 days)

Finally I started my work and my work took 4 days. I ended up delaying the schedule vs. finishing on time. I had local buffer but it did not help. Therefore having shorter iteration in development cycle might help in keeping the focus vs. big iteration.

Lateness passed down (Central Limit theorem does not apply for software)

Software tasks are mostly dependent upon each other, hence the impact of delay of one task may cause delay in other another too. Let me elaborate what I mean by this. Lets estimate a feature A, which has 3 tasks X, Y, Z.  Task X would take 4 days to finish. Y and Z subsequently would take 2 days each. So initial estimate for feature A is 8 days.

For some technical reason task A took 5 days. Now obvious question would be to think what impact would it have on tasks Y and Z? Developers would mostly say other tasks would finish in 2 days each, since I learnt a lot while finishing task X.

You might think that our new estimate for feature A is 10 days vs. 8 days.  If the tasks in feature A are independent to each other, than this new estimate might be good but in most cases if task X took 1 days longer there are possibilities that task Y and Z might take longer too.  Therefore for any revision, look for inter-dependency within tasks for more accurate estimates.  

my experience
Manisha