Estimate Time for Agile Estimation

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog


View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina
Jess Tayel
Ramiro Rodrigues
Linda Agyapong
Joanna Newman

Recent Posts

Bring on the Praise

Credit Where Credit Is Due

The Unsung Hero of a Mega Transformation

Victory Is Fleeting

Change Is Cool

Categories: Agile

Agile estimates and planning are essential to a project. But a common mistake during rough release estimating is forgetting that the opportunity for a greater level of detail comes later.
If that point is missed, teams may struggle during the initial high-level estimates.
To avoid that problem, I suggest that at the beginning of a project, teams do a rough estimate of each requirement. One common estimating technique includes "planning poker," also called Wideband Delphi. 

In planning poker, each team member secretly picks a number representing how much effort or complexity they think is involved in a given requirement. The numbers then are revealed. The person with the highest value explains to the team why it is hard. The person with the lowest value explains why it is easy.
After no more than two minutes of discussion, the team votes again. This process is repeated until the team reaches a consensus or it discovers there is not enough information to estimate this requirement.
The problem arises when teams blur the focus between the low-level estimates for a two-week iteration and high-level estimates for the release. Low-level estimates are more precise because they split a requirement into several tasks, estimated in hours. By contrast, the high-level estimates are in more abstract relative "points."

Some teams incorrectly attempt to identify predecessor dependencies in high-level estimates. They can also spend too long trying to refine the estimate or silo work between sub-teams to make two estimates for the same requirement.
This detracts from the goal of being able to estimate a large pile of requirements quickly and at the beginning of your project. Remember, there is plenty of time to deep dive later.

How long does it take you to estimate your project?

Posted by William Krebs on: July 02, 2012 11:17 AM | Permalink

Comments (3)

Please login or join to subscribe to this item
Ramesh Chalamalasetti
Yes, the author is right more from realtime perspective. Higher level estimates mostly are padded estimates. Progressive removal of comfort pads give raise to task level/lower level estimates. By this time much of the risk analysis happens and priorities mapped. Hence obviously lowerlevel estimates make sense. Wideband Delphi tech really makes sense to make our workings for estimates free at least from ideal constraints/assumptions (a case with higher level).

I like the idea of a "planning poker" process of estimating. It seems like it would add an element of fun to the schedule estimation process that would keep project team members well engaged.

Sarika Kharbanda
Utilizing techniques such as Planning Poker, I have seen quick and fun estimations among teams - allowing visibility to the employing organization and to the customer.

This has also allowed in the customer taking good business decisions, as might be needed at the right time. This has also allowed an increased cohesion in the team, also avoiding any halo effects. So, this Wideband Delphi technique has worked to provide benefit.

Please Login/Register to leave a comment.


"I do not know anyone who has got to the top without hard work. That is the recipe. It will not always get you to the top, but should get you pretty near."

- Margaret Thatcher