And, some managers want you to estimate the budget as well as the date. And now, you’re off into la-la land. Look, if you had any predictive power, you’d be off somewhere gambling, making a ton of money. But, you do have options. All of them require iterating on the estimates and the project.
First, a couple of cautions:
- Never, ever, ever provide a single date for a project or a single point for a budget without a range or a confidence level.
- Expect to iterate on the release date and on the budget, and train your managers to expect that from you.
- If you get a ranked feature set, you can provide working product in the order in which your managers want the work done, while you keep refining your estimates. This has to be good for everyone.
- If you can say this without being patronizing, practice saying, “Remember, the definition of estimate is guess.”
First, remember that a project is a system. And, a system has multiple aspects.
If you’ve been managing projects for a while, you know that there is no iron triangle. Instead, there is more of a project pyramid. On the outside, there are the typical corporate constraints: Who will work on the project (the people and their capabilities), the work environment, and the cost to release. Most often, those are fixed by the organization. “Bud, we’ll give you 50 people, 5 months, and this pile of money to go do that project. OK?”
Whether or not it’s ok, you’re supposed to nod your head like a bobble-headed doll. But, if your management has not thought about the constraints, they may be asking you to smush more features in insufficient time that the people can accomplish, given the requested time to release, with the expected number of low defects in the expected cost to release.
The time to release is dependent on the number of people and their capabilities and the project environment. You can make anything work. And, there are delays with geographically distributed teams, lifecycles that do not include iteration with long lists of features.
This is why estimation of the budget or the time to release is so difficult.
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’?”
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:
- 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.
- 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.
- 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.
You have options for estimation, once you have met the preconditions. If you don’t have the feature set in a ranked order, you are in trouble. That’s because if you use any lifecycle other than an agile lifecycle, the feature order matters to your estimates, and the team will discuss the feature order in addition to the size of the estimates. That will make your estimation time take longer and your team will not agree. It all starts to get stickier and stickier.
When You Have a Decreed Date
It’s fine to live with a decreed date—that means you get to manage the features. Now, you have a choice. You can work in iterations or in flow (kanban). Let’s assume you work in iterations for now.
Use Timeboxes, Better Your Estimate as You Proceed
If you have worked on a project like this, with this exact team before, so that you can use this team’s velocity, go ahead and use this team’s velocity and estimate the entire backlog with the team. I would timebox this effort to no more than 2 hours total. It’s not worth spending any more time on it, because your estimate is bound to be wrong. Why? Because this is new work you have not done before.
This estimate is the first date you cannot prove you cannot make. This is your most optimistic estimate. It is not the most likely estimate, nor is it the most pessimistic estimate. Well, unless you are all Eeyore-type people, in which case it might be the most pessimistic. But, I doubt it. I would take that estimate, and say to my manager, “Here is an estimate that I have about 50% confidence in. I will know more at the end of the third iteration.”
The team tracks its velocity for three iterations and re-estimates the entire backlog again, and see what it has for an estimate again, and compares what it now knows with what it knew before. Now, you have something to compare. You now ask the team how much confidence they have in their estimate. Report that to management. Maybe they have 50% confidence, maybe they have less. Maybe they have more. Whatever they have, report that to management.
Repeat estimating the remaining backlog until you get to 90% confidence.
When You Have a Decreed Date and a Decreed Backlog
Some of you are saying, “JR, my manager has also decreed the feature set.” Fine. As long as your manager has decreed the feature set in rank order, you can make this work.
You still need to know in what order your manager wants the features in. Why? Because if you look back at the project pyramid and the preconditions in Part 1, several things can occur:
- Your customers/manager may not want all the features if you demo as you proceed
- Your customers/manager may not want to pay for all of features as you proceed, especially if you provide an estimate and demo
- You are getting dangerously close to having too many fixed constraints on this project, especially if you have a fixed number of people and a fixed working environment. Do you also have a fixed cost? You are in the danger zone! I can guarantee you that something will not be fixed once your management or customers see the number of defects.
Obtain Data First, Then Argue
If the manager has decreed the date and the feature set why are you estimating anything? Get to work! This is when using timeboxes or kanban and determining your true velocity and performing demos is useful to show progress so your management can see what you are doing. They have no idea if their decrees/wishes are reasonable. I don’t think there’s much point in fighting with them until you’ve accomplished half of the ranked backlog or worked through half of the schedule. Once you’ve done half of the backlog or half the schedule, now you have data and can see where you are.
Now you can take your data, and use the previous option and provide estimates for the rest of the backlog with confidence ranges.
When I’ve been the project manager for imposed dates and imposed backlogs, I’ve explained to management that we will do our best, but that we will maintain a reasonable pace from the beginning and when we are halfway through the time and the backlog I will report back to management where we are. Did they want to know where we are a quarter of the way instead, where we have more flexibility?
That changes the conversation. Sometimes they do, and sometimes they don’t. It depends on how crazed the management is. I also protect the team from multitasking (none allowed). I am the Wall Around the Team, protecting the team from Management Mayhem.
Check out the next part.
Reference: Estimating the Unknown: Dates or Budgets, Part 1, Estimating the Unknown: Dates or Budgets, Part 2, Estimating the Unknown: Dates or Budgets, Part 3 from our JCG partner Johanna Rothman at the Managing Product Development blog.
