Estimating when the development team won't estimate

Question

I'm new to a situation where a development team refuse to estimate anything until they have a fully defined spec. My angle to obtain estimates is to provide just enough of a spec so they can provide an estimate that has a degree of confidence behind it for e.g. 6 months development time plus or minus 10%. Then I want to refine it over time and set the stakeholders expectations so that they know the estimate will improve. What other techniques could be used in a situation such as this where a lot of discovery is required up front on a large project with a team that pushes to only estimate when they have everything.

Answer 1

Per the Cone of Uncertainty, you won't be able to get estimates that have deviations of plus/minus 10% until much later in the project, at least after requirements engineering is complete. For a more agile approach, you would be able to estimate the sprint within this amount of accuracy after detailing the requirements to be implemented in the sprint. For a more plan driven approach, you need to finalize the spec first and even get into system design before you approach this level of certainty. The team also needs to realize this - it's very much acceptable (and well documented by experts such as Barry Boehm and Steve McConnell) for estimates to vary by 200-400% if you just have a concept and a portion of the requirements.

If you are looking for estimation techniques, there are plenty. If your development team consists of experts in the technology and domain, consider Wideband Delphi. It was first described in Software Engineering Economics. The idea is that you get your experts and have them estimate, then discuss and refine their estimates to come to a concensus. It's rather similar to techniques such as planning poker from Extreme Programming. Steve McConnell's Software Estimation: Demystifying the Black Art discusses a number of other techniques and tools for estimation, as well as working with both clients and development teams on estimates, schedules, and deadlines. Although it's geared toward project managers and technical leads, it is consumable by developers as well and I would highly recommend a copy of it.

For overcoming the team's lack of desire to estimate without a spec, I would work with them to explain why it is important that they at least try, even though you know there will be great uncertainty. This is a conversation and even a negotiation to come to an agreement, and there have been many books written on these subjects, and I have to recommend Getting to Yes, Getting Past No, and Difficult Conversations as three leading books on how to have these conversations and discussions.

Answer 2

First, it is a safe assumption that in software development industry you won't have precise estimates if you trying to plan 6 months ahead.

Second, despite of all the uncertainty of half-year-long estimates, and even more uncertainty attached to estimating incomplete or vague requirements, in vast majority of cases stakeholders need to know a general time span and general cost of a project. Is it going to take days, weeks, months or years? Do we need one developer, whole team, a few teams or the whole division? These questions are always valid, even if your approach is that you avoid estimating whenever possible.

In such case I would start with trying to understand why a development team refuses to estimate before full specs are delivered. I mean you will address the situation differently when they actually believe they are going to have their estimates right when they get the full specs than you will if they refuse to estimate as they've been constantly hit because they didn't have their estimates perfect.

Either way, to have anything to start with I'd ask the team for just a coarse-grained estimate, also known as wild ass guess, just for the sake of building general insight how much it can take to build the whole thing. Note: I would go either with multiple-point estimate, meaning it would take something between 3 and 6 months, or estimate with probability attached to it, meaning we have about 80% chance to complete it in 5 months.

Remember: development team has to be sure that if they are wrong, for whatever reasons, on this coarse-grained estimate no one is going to shot them. Otherwise they'd refuse to make any estimates at all.

Then your actions would depend on a situation:

• If the team believes that they can deliver perfect estimates if the specs are detailed enough I'd try to deliver such specs but gradually. Only one part of the project, one that the team is going to work on next, at time. At the same time I'd try to educate them that requirements are changing over time and even if you had full specs at the beginning of the project there wouldn't be much of value of even the perfect estimate as conditions would change, thus estimates would need to follow.

• If the team had bad experience with their previous estimates, I'd try to avoid estimating at all, besides coarse-grained ones that is. To give you insight how you're doing I'd focus on completing specific features as soon as possible and verifying how you're doing against the plan. One of examples of such approach can be measuring percent complete. This would allow you to discuss with stakeholders progress of the project and steer their expectations.

• In each case I would gather and use historical data, regarding how fast the work is being done, what is the pace of the team etc. Depending on a method you choose it can be called velocity, throughput, etc but either way you want to know how many features of roughly this or that size you can build in given time. It means that you need to use some method of sizing features, for example T-shirt sizing (S, M, L, XL, XXL), and then you need to gather data on how much it took to build the feature. I would also add how much time elapsed since you started working on tasks until it was done (lead time), as opposed to how much real work was done on the feature. Knowing that data and learning about trends can help you to tell how your team is doing even if they don't estimate at all or they estimates are worthless.

Answer 3

If the team doesn't feel like they have enough information to estimate, you should probably listen to them. Especially if you're trying to get +/- 10% on something the size of 6 months. Talk to them and see if there are specific concerns they think need to be addressed, or if they feel like there is insufficient information across the board.

It is possible (even likely) that the team has been asked to do estimates like this in the past and has gotten burned by it. They've likely seen instances where lack of some details in the requirements has lead to drastically different understanding between what they thought needed to be done and what the stakeholders actually expected.

If you haven't already done so, consider spending a couple days putting together story maps, including stakeholders as well as at least some portion of the development team. The development team can ask the questions where they see holes, and the stakeholders can fill them in. It helps ensure that everyone has the same vision of what is actually expected to be accomplished.

If the team thinks there are still significant risks, be willing to accept that either +/- 10% may not be achievable, or you are going to have to decide whether you can ensure that risks and scope are managed correctly during development.

Answer 4

You are asking the team to make cost estimates when they do not have enough information. To do this, they will have to make assumptions, and they are refusing to do this, because it has bitten them in the ass.

There are two ways to solve this. One way is to make sure it will not bite them in the ass. Ask yourself: "Have I ever provided my team with a fixed-scope fixed-budget fixed-quality assignment, referring back to their initial estimate on unclear specs?". You probably have.

The other way is to remove uncertainty. If they refuse to make any assumptions, you have to make the assumptions for them. Answer every question they have, assuming either worst case, best case, or a realistic in-between. You can then communicate their estimates very clearly, because you know the assumptions behind them. Ensure broad functionality is split into smaller user stories to reduce uncertainty.

Answer 5

Please consider the games presented by James Grenning: http://www.renaissancesoftware.net/blog/archives/36 In particular, deal-and-slide has done me well. These games really seem to take a lot of the time out of the exercise and make it more fun.

A lot of the trouble you're having is that the team is afraid that any number they give is a hard commitment, or will be seen that way by managers further up the chain of command. If you pull them together to get rough sizing with the intent of making estimates later, you might have more success. Of course, if a number of "size one" stories are done and all take two days, you'll have a sense of what "size one" stories are.

Answer 6

In essence, high-level specification can produce only high-level estimates.

Think of it from the developer's perspective. You are asking them to estimate and commit to a big unknown. It is like asking how much is to buy a nice car.

There are several approaches suggested already. Mine would be:

• Try to get +/- 50% estimate, and re-estimate as you get more info about the scope. Make sure that you explain the process to the developers, because if you hard-press them for estimates they will over-estimate to protect themselves.

• Use parametric estimations. How much did a similar piece of work cost, or take time? Take into account seniority of developers involved, their availability, are they spread across several projects, etc.

But, whatever approach you take, you'll have to re-estimate the project on a regular basis and all stakeholders should be aware of the approach and the situation.

Another issue here is the fact that the team is reluctant to provide any kind of estimates. It is usually because there is no trust in the team, or between the teams. Potentially it could be a huge issue and it should be addressed promptly but carefully.

Answer 7

Change the consequences (real or perceived) of the team over or under estimating. It sounds like they feel they will be held to the estimate with dire consequences if they get it wrong.

If you are producing fixed price quotes for clients based on those estimates, you will get burned (particularly with only 10% - 6 months ahead you should factor in a minimum of 50% deviation). This creates a huge disincentive for the team to estimate.

Consider moving to hourly pricing, build in higher margins/reserves and improve your requirements gathering process. All of these will change the environment in which the estimates are produced and therefore change the dynamic between the pm and the team doing the estimating.