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

RSS

Recent Posts

Fair's Fair

Give Your Project a Home

A Hollywood-Style Move From PM to Scrum Master

To Have and To Hold

Leading With Integrity

Email Notifications off: Turn on

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

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

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

ADVERTISEMENTS

"A jury consists of 12 persons chosen to decide who has the better lawyer."

- Robert Frost

ADVERTISEMENT

Sponsors

>