Agile Zone is brought to you in partnership with:

Peter Schuh coaches project teams and conducts trainings in the adoption and improvement of agile practices and techniques. He excels in both agile and traditional development environments (such as waterfall, heavy process and fixed cost). Peter is also the author of "Integrating Agile Development in the Real World," a field guild for software development professionals who aim to deliver useful and usable software in a timely manner. Peter is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. You can read more from them at their website. View Full User Profile

That Huge Estimate May Be a Vote of No Confidence

01.04.2011
| 2014 views |
  • submit to reddit

sprayfoamI’ve seen it happen several times. The business requests an upfront, full-cost estimate for some feature or functionality. A business person writes something up – far simpler than the normal story-writing or requirements-drafting process. The development team reviews the write-up. Questions, clarifications and adjustments happen. An estimate is assembled and then KA-BLAM! – everyone is blown over by the sheer size of it.

When even the development team is left scratching its head saying: “Yeah, that looks way big to us too, but … ” you know there are problems bigger than whatever comes after that ellipses.

Granted, there are mitigating circumstances. The requirements – such as they are – may delve into a new and unknown domain. The technology may be novel to both the team and the corporate IT ecosystem. But even in these cases, if the team cannot mount a strong justification for an eye-popping estimate, you have to ask whether there are other issues lurking in the shadows.

In these cases, the two most common issues I’ve set alight are:

1. The delivery team lacks confidence in its own technical ability (due to a skills mismatch, lack of training, or other reasons). This issue goes beyond the time it might take to ramp up on new technologies, adjust to a new domain, or proof a novel design approach. Teams can readily explain all this in their estimates. But an intractable problem arises – with a huge estimate in tow – when the development team fears that it’ll never fully tackle a new technology, domain, or approach. Or, sometimes, it’s an unconquered legacy technology, domain, or approach frustrating future development.

2. The delivery teams lacks confidence in its business partner’s ability to honestly collaborate and openly negotiate with the team. It’s okay if the business partner doesn’t get the requirements solidified on the first, the second or third try. Agile teams know this can be difficult, and agile processes are geared to accommodate. However, when a customer repeatedly demands prompt and accurate delivery on half-baked requirements, even an agile team will take a tanker-truck of spay foam to the delivery estimate.

While the causes are dramatically different, the end result for each issue is the same. The team’s huge estimate reflects an inability to adjust and adapt. In one case the team lacks confidence in its own ability; in the other case the team lacks confidence in its customer. Regardless of the cause, these are issues that need to be addressed, as they impede far more than the team’s ability to deliver an estimate.

Sometimes a huge estimate is just a huge estimate. Sometimes it’s something much more. Next time you see a jaw-dropper of an estimate wrapped in flimsy explanation, it might be worth taking the time to find out why.

References
Published at DZone with permission of Peter Schuh, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Prem Kurian Philip replied on Tue, 2011/01/04 - 10:21pm

There are at least two other possibilities: * The delivery team is considering a non-optimal way of solving the problem. Example: instead of customising an existing solution which may already have a lot of the features, they are building it from ground up. * The requirements may be huge which results in a huge estimate. I have had this happen multiple times when clients want a solution which combines the functionality of Google docs, Google calendar, linkedin, facebook, ... etc but they are want it all done from ground up in 2 months time.

Peter Schuh replied on Tue, 2011/01/04 - 10:42pm in response to: Prem Kurian Philip

Agreed that both of these are good explanations for a HUGE estimate.

And the team that selects a sub-optimal solution may have toouble justifying it -- which indicates a bigger issue.

Two months to integrate Google docs, Google calendar, linkedin and facebook makes me cringe. I've defenitely seen enough of that as well.

 -Peter

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.