How to give IT project estimates—and when not to estimate at all
Celeste felt squeezed. Her manager, Barry, wanted an estimate for her team’s quarterly deliverables. Making the task more challenging, Celeste’s team wasn't working on just one product; no, Barry wanted estimates for three different products. Each product was part of a different project.
Celeste’s team members didn’t feel they knew enough to estimate anything, never mind develop predictions for the entire quarter.
Celeste decided to come clean with Barry and see what they could agree to. She arranged a meeting for the next day and gathered her data.
She arrived at Barry’s office at 10 a.m. on the dot. When she knocked on the doorjamb, Barry was still on the phone. He motioned for her to come in and held up one finger, to say he’d be done in a minute.
She sat down in his visitor chair across from his desk.
He hung up the phone, turned to her, and said, “Let’s talk estimates, shall we?”
Celeste nodded, and said, “OK. Here’s what I think we can do.”
Barry furrowed his brow. “Think? I need a commitment. No 'thinks' here!”
Celeste sat back. “Barry, are you under pressure to deliver these three products?”
“How could you tell?” Barry asked. He shook his head. “To hear sales and marketing talk, it’s a disaster if we don’t get these products out, and now. I don’t know what to tell them except that we’ll do it all.”
Celeste shook her head. “What about the project portfolio discussions you had last month? I thought product A was the top priority.”
“It is,” he said. “And products B and C are also top priority.”
Celeste rolled her eyes. “You do know there can be only one top priority, right?” she asked.
“I know it and you know it,” he said. “But my colleagues don’t appear to know it. I need estimates of what you can do—well, commitments—and then I can get us some breathing room.”
“Which product do you want us to work on first?” Celeste asked.
“Product A, of course,” he said. “It’ll give us the biggest bang for the buck.”
“OK, here’s what we’ll do,” Celeste said. “We’ll work on A and deliver all through this coming month. Your job is to get those nice people to attend our demos every week. They need to see what we can do in a week. If they don’t come to the demos, I refuse to give them any information at all.”
Barry leaned back. “Hold on. I get the demos piece. What about the other two months? And why won’t you give them any information?”
Celeste said, “If we only worked on one product at a time and finished it, I could provide estimates based on our cycle time. We do roughly three to four stories [code for user-defined tasks] a week for product A. We don’t know our real cycle time for products B and C.”
Barry nodded. “Why not?”
“B and C are in months two and three,” Celeste said. “That’s kind of far out for marketing. The problem is that the further out the work is, the less ‘time’ the marketing department has to work with our product owner to refine the stories. We have no idea what those supposed features are for months two and three. We would be making a scientific wild-ass guess (SWAG)—which is fine. I’m happy to SWAG with the team, but we need more specifics for the requirements. Which we don’t have.”
“So, why won’t you give them any info if they don’t come to the demos?” Barry asked.
“If seeing our progress and providing feedback on it isn’t important enough for them to show up, then they don’t really want estimates,” Celeste said. “What they want is for us to commit to them without the reciprocal commitment. Why should I waste any time on estimation when they won’t commit to us?”
Barry agreed to “sell” a one-month timebox to the users pressuring him for a commitment. Celeste would work with the team to make sure it focused just on product A. And she set up the meeting invitations for the weekly demos to make sure the team could show its work and receive feedback.
Would you have been tempted to do things differently?
Estimation is non-trivial work
Estimation is work, too. Many teams account for estimation in their regular flow of work. However, an accurate estimate for a quarter’s worth of work often requires more than the hour or two of estimation as the team proceeds.
There are at least two problems with estimating a quarter’s worth of work: Too often, the requirements aren’t fully defined and, as with Celeste’s team, the estimation interrupts the team from its urgent project work.
The problem is that software estimates are not like an estimate for a road trip. If you live anywhere that has more than one traffic light, you’ve encountered traffic fluctuations. I live in the Boston area, where a drive to the airport can take me 20 minutes or 90 minutes. Most often, it’s in the range of 30 to 45 minutes. That’s substantial variation for an eight-mile drive.
And there’s no innovation in that drive. I have driven to the airport many times, and I know several ways to get there. I have mobile apps that help me discover the fastest route even on my way. While some of the variations can give me slightly better predictability, none of them can assure me that this specific trip can be done in 20 minutes.
A drive to the airport has a predetermined path and well-understood slowdowns. However, product development is nothing like a drive to the airport—software is all about innovation. That means we haven’t done anything exactly like this before. If we had, we wouldn’t need to write this new application or update a legacy system; we’d use the old one.
To create a reasonable estimate, we have several options. Three, in fact:
- We can provide an order-of-magnitude estimate. I find this helpful for an entire project. “We think it’s between five and nine months of work. We’ll know more when we answer these questions and finish that part of the complex work.” SWAGs might be good for these estimates.
- We can learn enough about the requirements to provide a reasonable estimate. That might require the team to workshop the stories to create an estimate with a small enough variation to set everyone’s expectations.
- We can estimate the requirements for a short time, such as a week or two of work. We might learn we didn’t estimate everything correctly. However, we are generally close enough that we don’t disappoint the people who asked for the estimate.
Which estimate does the manager need?
I’ve found that managers often need the order-of-magnitude estimate. In that case, the team can create an estimate and might report it like this:
“We estimate this project will take five months to complete, with a 50 percent confidence in the accuracy of that prediction. If we say eight months, we have 80 percent confidence of delivering on time. Ten months is 90 percent confidence.”
That helps the managers see there is a range of confidence. If the managers want 100 percent confidence in the estimate, that might not be possible until 14 months.
You might use the spiral-in method. “We’re aiming for the first quarter next year. We don’t know when in the first quarter, but we think we’ll make it.” As the project proceeds, you might say, “We can update the estimate to somewhere between mid-January and mid-March.” When you know more, you can say, “Sometime in February, assuming we don’t have a blizzard.” Then, in January, you can say, “Third week of February.”
I’ve also used the three-date range: “Our most optimistic date is sometime in January. Our most realistic date is late February. Our most pessimistic date is late April.”
Whatever you do, do not provide a single-point estimate. That tempts Saint Murphy (of Murphy's law) to sit on your project and cackle at you.
In some cases, and with some teams, product owners might need more specifics. Here, you can workshop stories with the product owner to understand the uncertainties. That allows the team to estimate stories for a few weeks out and for an iteration.
Use cycle time instead of estimation
I’m not a fan of estimates for software projects or other IT projects, especially for agile projects. Instead, I prefer that the team deliver very small stories and either use cycle time or counting the stories.
If you’re unfamiliar with the terms:
- User stories describe how a customer or user employs the product, usually with a single functional goal (“I want to make a reservation” or “I need to publish smart city data to satisfy transparency requirements”) rather than from a developer’s point of view (which would speak in terms of databases and APIs).
- Cycle time refers to the total time it takes for the team to deliver finished work in the form of a story. That includes both the active time, during which the team works on the story related to the task being worked on, and the delay time, when the work is idle while waiting for something to happen.
The idea is that you understand the average time it takes you to finish something of value (the story).
In Celeste’s case, she knew her team could deliver three to four stories a week for product A. For many teams, counting stories works as well as going through the various kinds of estimation.
If a team has never worked on a similar product, its previous cycle time won’t be applicable to this new product. The team might not know how to refine the stories to be small enough to deliver several stories in a given week. In addition, it might not know the state of the code and whether enough tests exist. If your team has stories that take longer than three days, don’t bother estimating. Count them and don’t try to commit to more stories than you normally can complete.
Once your team has one- or two-day stories (that is, the time it takes to code the functionality for a single user story), you don’t have to estimate either. Counting is easier and often more accurate.
Why not use velocity?
You’ve noticed I recommend cycle time and counting stories, not velocity, as a team measure for estimation. That’s because velocity is a surrogate measure of capacity. Velocity is not acceleration.
For example, I walk every day to maintain my fitness. I walk the same route every day to track my relative speed. On a comfortable, sunny day, I walk about 3.5 miles per hour. On a rainy or hot and humid day, I’m down to 2.5 mph. On a snowy or icy day, I might not even go outside, in which case, my velocity is 0.
I walk the same route. (Yes, I’m boring, but that’s my problem.) While I cover the same distance, the journey takes me different times depending on the underlying conditions. My underlying conditions are similar to your team’s code base and tests.
If your team’s stories are small enough, your velocity mirrors your cycle time. Too often, I see teams with very large stories try to give an overall estimate. Counting would be easier: “We can finish one or two stories in an iteration. Which one or two do you want?”
It isn’t cheating to choose not to estimate
When Barry discussed the issues with his colleagues, one of them replied, “Not estimating is cheating!”
Barry said, “No, it’s not. You want us to deliver product A, right?”
The response was, “Sure. And B and C.”
“The problem is, you can only get one at a time," Barry answered. "If you are in such a rush for product A, what’s the point of estimating? We can get to work and show you what we’re doing. When we’ve done enough, we’ll do the same for B and C. Plus, you’ll have time to refine the requirements, so the stories are ready for us.”
Celeste’s team completed enough for product A in one month. Product B took longer to deliver enough—closer to two months. And because the company had sufficient revenue from product A and B releases, the pressure was off for product C.
Know what kind of an estimate your manager needs. Say it in a way the manager needs. And if you’re squeezed for time, get to work.
Estimating IT projects: Lessons for leaders
- Don't give a single specific number or date. Instead, give an order-of-magnitude estimate that includes your confidence in delivering on time. Or offer short-term estimates based on the factors under your control.
- Separate the project tasks into user stories that define the software's functionality. Then make your estimates based on the number of user stories you can deliver.
- Make sure you understand the requirements before you make any kind of commitment.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.