Over a million developers have joined DZone.

Estimating the Unknown: Projects or Budgets, Part 2

DZone's Guide to

Estimating the Unknown: Projects or Budgets, Part 2

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

(Free Estimation Ebook)

So now that you know why it’s so difficult to estimate what do you do when someone asks you for an estimate?

Preconditions for Estimation

First, you ask a question back: “What’s most important to you? If it’s 3 weeks before the end of the project, and we haven’t finished all the features and we have ‘too many’ defects, what are you going to say?

  • Release anyway? That says time to release is king.
  • Are you going to say ‘these features better work’?
  • or are you going to say, ‘these defects better not show up’?”

Project Pyramid

You can have only one #1 priority in any given project or program. You might have a right-behind-it #2 priority and a right behind-that #3 priority, but you need to know where your degrees of freedom are.

Remember that project pyramid from before? This is your chance to rank each of the vectors in the pyramid. If feature set is first, fine. If time to release is first, fine, if cost is first, fine. If low defects is first, fine. Whatever is first, you don’t really care, as long as you know and as long as you only have one #1 priority. You run into trouble on estimates when your management wants to fix two out of the six sides to the pyramid—or worse—more than two sides.

When your managers say to you, “Here’s the team, here’s the office space, here’s the budget, here’s the feature set, and here’s the time,” you only have defects left to negotiate. And, we all know what happens. The defects go sky high, and you also de-scope at the end of the project because you run out of time. That’s because you have too many fixed constraints.

Insist on a Ranked Backlog

If you really want to estimate a date or a budget, here is how to do it. You have these preconditions:

  1. You must have a ranked backlog. You don’t need a final backlog. You can certainly accommodate a changing backlog. But you need a ranked backlog. This way, if the backlog changes, you know that you and the team are working on the work in the correct order.

  2. The team who will do the work is the team who is doing all the estimation. Only the team who is doing the work can estimate the work. Otherwise the estimate is not useful. Surrogate estimators are biased estimators.

  3. You report all estimates with a confidence range. If you report estimates as a single point in time, people think your estimates are accurate and precise. If you report them as a confidence range, people realize how inaccurate and imprecise your estimates are, and you have a shot of people treating them as real estimates.

Once you’ve met the preconditions, you can estimate. And the reason I have projects or budgets in the title of these posts is that the same reasoning works for both project dates and budgets. Hang in there with me, all will be clear at the end.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}