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.


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.

  • 1
    +1 for a great summary of 'ways of estimating' and plus/minus 10% won't be possible very early. I'd like to make a point explicit here - the 'metric' required for estimation (i.e., SLOC/FP/Story, use-case points etc.,) may govern the choice of technique - estimating SLOCs maybe very problematic if multiple technologies/languages are involved. FPs are not too easy either - story points would be good even if they are very early. It's the team 'velocity' that would normalize the initial guestimate of time to complete. So choose the approach wisely and weigh its pros/cons before doing so :) – PhD Dec 5 '11 at 1:51

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.

  • 3
    I disagree with avoiding estimation. You should be estimating at the appropriate granularity for the given information, since the only way to improve is to continually develop an estimate, perform the work, and determine why the estimate and actual times vary and what to do about it. If you have had problems with previous estimation attempts, consider those when presenting estimates to clients or when building schedules by, for example, adding a small amount of variance (team says 75% confidence, call it 70% confidence when building the schedule, for example). – Thomas Owens Nov 30 '11 at 13:04
  • @Thomas - Whats the point of estimation? To get insight how much a project is going to take/cost you. Consider you can get this insight basing on historical data and little or no estimation effort at all. Now, again, what's the point of estimation in this case? We know what we wanted. Estimation shouldn't be done just for the sake of estimating. Think of value you get from this activity. – Pawel Brodzinski Dec 7 '11 at 11:58
  • Using historical data is a commonly used estimation technique that forms the basis of PROBE, Evidence-Based Scheduling, COCOMO, Wideband Delphi, and Planning Poker. You can, and should, use historical data for the initial estimates, but revise those estimates based on current project factors, ranging from team size to familiarity with technology to the projected effort/week. PSP Level 2 and CMMI Levels 4 and 5 call for continuous process improvement, including improving estimation. If you don't appropriately track and analyze estimates for accuracy, you can not meet these requirements. – Thomas Owens Dec 7 '11 at 12:29

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.


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.


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.

  • Great concise answer! – Alan Larimer Jan 9 '18 at 15:18

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.


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.

Your Answer

