Welcome to MSDN Blogs Sign in | Join | Help

Progressive Development

Zany Adventures in Software Engineering with Maven and Motley
Motley says: "Individual gut-feel estimation is the only way to estimate"

Summary

 

Motley:  Estimation is always inaccurate. Individual gut-feel estimation is the only way to go.

 

Maven: Wideband Delphi is a valuable estimation technique that can immediately improve your accuracy.

______________________________

 

[Context:  Motley is about to estimate the amount of effort to develop a new feature and is reflecting on the difficulty of estimation]

 

Motley: You know, sometimes I really wonder what the point is of estimation. Developers are never accurate on any project longer than 3 days!  The only real way to estimate is to go off gut feel and leverage the PANOOMA technique.

 

Maven: You're right - estimation is hard. But, fortunately there are some techniques we can leverage to improve the accuracy of our estimates. And by the way, what is the PANOOMA technique of estimation? That's not one I have heard of.

 

Motley: Pull A Number Out Of My Ass! That's really what ends up happening anyway.

 

Maven: Ha! Let's just call that "gut feel" estimation from now on, shall we? Anyway, have you tried basing your estimates on past projects?

 

Motley: Yeah, I try to compare what I am working on now to what I have worked on in the past, but I must admit that I usually miss something and end up blowing the estimate. It's frustrating. My boss doesn't trust me to delivery anything on time these days. I've heard of some more scientific techniques of estimating and some software packages that facilitate a more accurate estimation, but I'm not sold. Many of them also require lots of historical data, which I don't have.

 

Maven: Have you ever heard of Wideband Delphi estimation? That technique could help you out.

 

Motley: No, never heard of it. Not sure I want to. It sounds like it's extremely mathematical suited for pocket protector geeks and way overkill for our projects. And NO, I don't want to hear about it.

 

Maven: That's not the attitude I'm looking for!

 

Motley: Yeah, well, you're going to tell me anyway, so please just get it over with so I can get back to more meaningful activities, like lunch.

 

Maven: That's the spirit! I think. Wideband Delphi is a very easy estimation technique to learn. There's really not much to it, and it's not scientific or highly mathematical. Instead, it leverages the wisdom of crowds.

 

Motley:  Hey, I've read that book! It surmises that an uninformed crowd can often make a better prediction than an informed individual. My buddies and I use it all the time when buying our weekly lottery tickets, but it never seems to help.

 

Maven: You're right on the synopsis, although lottery tickets is not the best application. Wideband Delphi leverages the "wisdom of crowds" concept using the following lightweight process:

  1. Get a group of people together that can help with the estimation exercise.  It is not important that everyone be an expert in the domain or the technology upon which the estimate is based.
  2. Have the person that knows the most about the requirements for the work to be estimated give a quick overview of the work. "Quick" implies a minute or two - nothing too detailed.
  3. Next, everyone takes a bit of time to think about the problem and write down their assumptions on a piece of paper or index card. These assumptions are just for you, as a reminder when the discussion portion of the process arrives in step 5.
  4. Once you have noted all of your assumptions, you come up with one effort estimate in unloaded hours (no buffers, distractions, but instead pure effort in ideal developer days). Write down the number on a Post-It note, index card, or piece of paper and place it in the middle of the table upside down.
  5. Once everyone has finished their thinking and written down a number, the estimates are revealed. A facilitator (anyone on the team can play the role) then notes all the estimates and a discussion ensues, focusing on the assumptions that everyone made. The facilitator then notes the team decisions that are made. Once the discussion has completed, you go back to step (3) and iterate until the numbers suitably converge. The team could agree on a final number or just use the mean.

 

Motley: Interesting. You are leveraging the experience of other people to help you with your estimate. I bet once you turn over the estimates in the first round that the numbers are all over the map!

 

Maven: Almost always! In the first round there are lots of unknowns and everyone has a slightly different take on what it takes to get the job done. When estimating a coding task, Mary may include a code review but Marvin may not. Marty may assume that he is doing the work and has expertise, but Marcus assumes that the new intern is doing the work. The discussion helps focus the team on what is required to get the job done. By learning about everyone's assumptions and making some initial decisions as a team, you inherently lead to more refined and accurate estimates. Plus, you document the team decisions and can back up your numbers to whoever asks, like management.

 

Motley: But why does everyone have to put their number upside down on a sheet of paper. Why not just tell everyone your estimate?

 

Maven: Good question! We do this for a couple of reasons. Firstly, you don't want to bias anyone with your number, so you keep it quiet and they are all revealed at once. Additionally, keeping estimates anonymous allows you to go with your gut without being pressured by others in the room. For example, if there is a high ranking architect with lots of experience in the estimation session and everyone hears her number first, they may be inclined to just go with it. However, everyone in the room adds value and should have their assumptions heard. Keeping it anonymous removes a bit of pressure.

 

Motley: This seems way overkill for a smaller project with fewer unknowns. I'm still back to gut feel estimation and this won't help me much. Unless, genius, you have a solution for that too?

 

Maven: You know me, Mot. I have a solution for everything! And for that, we need to talk about a related estimation technique called Planning Poker...

______________________________

 

Maven's Pointer:  The most effective Wideband Delphi sessions involve estimators with different perspectives that also use different estimation techniques to derive their numbers. If one person uses Proxy-based estimation, another uses gut feel, and another uses Function Points, you can be pretty confident that the overall team number is accurate as it was arrived at using various techniques.

 

Maven's Resources: 

  • From Bouncy Balls to Better Estimates, by James Waletzky, MSDN Magazine, January 2007.
  • Wideband Delphi Wikipedia entry
  • Software Estimation: Demystifying the Black Art, by Steve McConnell, Microsoft Press, ISBN: 0735605351, March 2006
  • The Wisdom of Crowds, by James Surowiecki, Anchor, ISBN: 0385721706, August 2005.
Posted: Tuesday, September 25, 2007 7:53 AM by James Waletzky
Filed under:
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker