Share via

Point for Maven - Wideband Delphi Estimation works!

  • Article

  • Summary

  •  

  • Motley:  I admit it - Wideband Delphi works! It helped us generate fairly accurate estimates for longer-term planning and the documentation of our assumptions kept everyone on the same page and provided rationale for our numbers.

  •  

  • Maven: Um, what Motley said.

  • ______________________________

  •  

  • [Context: For the past few months, Motley and his team have been using the Wideband Delphi process for their estimates. Over the winter holidays, Motley got curious about the effectiveness of the technique]

  •  

  • Maven: Hey, Mot. Happy New Year, and welcome back to the office! Did you have a good holiday season?

  •  

  • Motley: Yeah, it was a good break. Although most of the time was spent with family and friends, I did do a bit of an analysis of some previous estimation data.

  •  

  • Maven: You have me curious - what's up?

  •  

  • Motley: A few months ago you gave the team some pretty good advice, I must admit. We used Wideband Delphi Estimation as you talked about before to estimate some key features for the product. The team used Scrum and gathered a bunch of data on how long it actually took us to implement the features, and I thought I would show it to you.

  •  

  • Maven: Sweet! Glad you were able to put it to use and see some positive results. Don't keep me in suspense!

  •  

  • Motley: Hold your horses, Mr. Impatient. First, a bit of background. This feature team was responsible for developing a feature with a bunch of subcomponents. We used Wideband Delphi to estimate all of the subcomponents early on in the project when we really did not know a whole lot about what we were estimating. Wideband Delphi was perfect for this exercise due to the large amount of project variability at the beginning.

  •  

  • Maven: How many people were involved with the feature team?

  •  

  • Motley: There was one program manager (PM), two developers, and two testers for the majority of the project to this point. That's not relevant for this analysis, however, as all work was estimated for one developer and computed the hours across all developers.

  •  

  • Maven: Makes sense. Any more background?

  •  

  • Motley: Yeah. One thing I would recommend to everyone is to have whoever is responsible for the initial high-level requirements put together a short 2-3 page document that describes the feature at a basic level, including some mock screenshots if necessary. It doesn't have to be highly detailed but should provide a high-level idea of what we will be building. Think of user stories, but to a slightly lower level of detail (but not much). Then distribute the doc to everyone involved in the estimation session to prepare. Have the author of the short document give an overview just prior to following the Wideband Delphi process to set context.

  •  

  • Maven: Great suggestion. Who did you invite to the session?

  •  

  • Motley: We invited the PM, the two developers, one tester and one senior developer from another team. One thing that worked really well was having that expert external to the feature team to help bring another perspective.

  •  

  • Maven: Okay - let's see the data already!

  •  

  • Motley: Hmmm… maybe I should make you wait a little longer. I love seeing you squirm.

  •  

  • Maven: You really are a mean person.

  •  

  • Motley: Just the way I like it! Fine. Fine. Here are a couple of graphs of the data I gathered:

  •  

  •  

  •  

  • Maven: Not bad data, Mot! Looks like many of your estimates were fairly close to the actual work on inspection. How do you explain the estimate for feature 6, which was quite far off?

  •  

  • Motley: That's easy - what we thought we were going to build at the beginning of the iteration actually turned out to be quite different. We did the estimate fairly early in the project and made some key assumptions, but later we discovered a couple of those assumptions were not valid. As a result, when we planned the iteration, we revisited our assumptions and realized we had more work than we thought we did. Don't forget - I am comparing our original estimates at the start of the project to our actual numbers. Secondarily, a dependency that we relied upon for that feature was late on their deliverable, so we did a bit of extra work to mitigate that.

  •  

  • Maven: Sounds reasonable. What about intuition - do you feel that Wideband Delphi gave you increased accuracy in your estimates.

  •  

  • Motley: Overall, gut feel is that Wideband Delphi gave us greater accuracy than we would have gotten had we left the estimate up to one developer. Everyone was happy with the process and has committed to keep using it.

  •  

  • Maven: As we talked about in the past, Wideband Delphi helps the team get on the same page at the start of the project. Did you observe that?

  •  

  • Motley: Wideband Delphi really helped us get on the same page with assumptions and come up with an initial direction people were happy with. Even though some of our assumptions changed later in the project, for long-term planning purposes at the start of the project, the data was accurate enough for the release management team to make reasonable predictions.

  •  

  • Maven: So you would use Wideband Delphi again?

  •  

  • Motley: Absolutely. You hit a home run with that one, Mave.

  • ______________________________

  •  

  • Maven's Pointer:  Our team at Microsoft uses Wideband Delphi consistently for early-project planning. When the management team forces us to come up with estimates that help define the milestone plan for the next 3 months, we use Wideband Delphi to generate not only fairly accurate numbers but also document the rationale behind the numbers. Even though detailed planning and scheduling for the next 3-6 months is fraught with peril - a realization agile teams come to - to be an agile team in a waterfall organization you must periodically give in to the will of the release management team.

  •  

  • Maven's Resources: 

    • Agile Estimating and Planning, by Mike Cohn, Prentice Hall PTR, ISBN: 0131479415, November 2005.

Comments