Comparison to Past Experience
Let’s apply the comparison approach to software development estimation.
What past work was similar to this work?
Is this yet another custom report for the business? Or a starter website for yet another small company? Sometimes our projects are amazingly similar to what we’ve done in the past.
Other times, they’re startlingly different. That’s not surprising. If we already had software to do what we wanted, we probably wouldn’t be starting a new project. It could be something that no one has ever done before, or, at least, no one that we know.
More often it’s somewhere in the middle, with both similarities and differences from our past experience. What projects in our experience have the most similarities? You may want to choose more than one, especially if they’re similar in different ways or to different parts.
Once we’ve chosen a piece of work that’s comparable to the one we’re estimating, we can ask ourselves questions about how it compares.
How does that work compare to this work?
Is this work about the same size, bigger, or smaller? Note that we’re saying “about the same size.” We’re estimating, not calculating. We’re not generally concerned if this work might be 2% larger or smaller. We’re probably not concerned if this work might be 10% larger or smaller. We’re unlikely to have enough accuracy to warrant that precision. If this work is 100% or more larger, we might want to take notice.
How does this work differ from that work?
Asking how the work is the same is helpful for sizing, but it may encourage you to overlook some variations that make a difference. Turning the question around helps you spot the uncertainties. You may want to temper your estimate with those uncertainties, or investigate to learn more and reduce the uncertainties.
How many of those bits of work would it take to make up this work?
Don’t jump to big numbers. How would you tell that something anticipated seemed 100 times as big as something remembered? How would you tell the difference between that and 1000 times as big? When you feel the need to use orders of magnitude, that’s a signal that you can’t really judge the size relationship—judging something as eight or 10 times (some parameter) may already be too hard. People, in general, aren’t very good at precise comparisons of things widely differing in size. Doing so for something as intangible as software development is even harder.
When you’re facing a new software development project, you can use the same familiar skills you use in your everyday life. But it’s a little different, of course. Undeveloped software is more abstract, and you likely don’t estimate it as frequently. For those reasons, and because you may have important consequences riding on the outcome, be a bit more mindful about how you go about it.
We just talked about comparing size in terms of multiples of our reference. Other times we might find a similarity to our reference, but there’s something additional. Or we may find both. And, of course, we might substitute division for multiplication and subtraction for addition, if it seems appropriate to us. Let’s look at such adjustments in more detail.
Multiplicative and Additive Adjustments
What’s the difference between your previous experience and your current one? Maybe you had a development project last year, but this one seems more complicated. Or that first one used a familiar technology stack but this one is based on new technology that none of us have used before. It’s still relevant experience. You’ll just have to adjust your expectations to account for the differences.
If this project seems more complicated, how much more is it? Twice as complicated, or 10 times? You can make a rough multiplicative adjustment to your past results to approximate your expected results.
What Can We Tell Them?
Sidney, the Internal IT Director of Empire Enterprises, called his top project manager, Marion, to his office. "I’ve just come from a meeting with the Customer Service department, and Ryan and Tracy say it looks like we’re going to have to bite the bullet and replace the call center software. What do you think that’s going to take in time and labor?"
"What do they want?"
"Basically a rewrite of the current system, plus some additional work to add metrics for auditing."
"That’s not nearly enough information to start work. I’ll need to research the current system, research the current usage, and get some details on the driving force behind the metrics."
"What can we tell them right now?"
"Given the need to research the requirements, I’d say roughly twice what it took to build the old system. And another 25% to add the metrics. I’ll have to research what the old system took to build to convert that to numbers. That’s a rough order of magnitude. Should I start working on a more refined estimate?"
"I don’t know, yet. Let’s at least look at the costs of the old system so we can give this in numerical terms."
That’s an example of a multiplicative adjustment. Even the additive part for the metrics was expressed as a multiple of the original project. This lets us compare to a project without knowing the numbers, yet. Next we’ll need to calibrate to the actual time and effort of that project.
Foreseeable Delays
If you need to learn a new technology, then how long will it take you to come up to speed? That’s an additive component to our estimation model. If last year’s project took you six months and it’ll take you two months to learn the technology, then eight months might be a reasonable estimate for this work. Or, since you’ll have much less experience in the new technology, perhaps there’s a multiplicative adjustment, also, to account for the friction of working in unfamiliar territory.
Considering the Learning Curve
Marion walked into Sidney’s office. "I’ve got some bad news. I’ve asked around about who knows anything about the last call center project. No one does. It seems that all those people have left the company, taking all of our call-processing expertise with them. I guess we’ll have to hire someone with that experience. That’s going to take three to six months, and then longer for them to bring the rest of the team up to speed."
Do you have a different set of people this time around? Will they work together as well as the previous group? How long will it take them to bond well as a group? Will they jell as a team and will their synergy surpass the historical comparison?
The further our reference experience is from the upcoming work, the more you’ll have to adjust that model to predict the future. And the more you have to adjust our model, the more likely it is for error to creep in. How do you know how much to adjust? That, too, is an estimate.
You make things harder on yourself when you make unnecessary changes in the way you work. Often people dissolve the team at the end of each project and build a new one for the next project, thinking they can more efficiently include just the skills they need. There are big benefits of keeping durable teams together and bringing the work to the team. One of these is having a track record for the team and how effectively it works together. Another benefit is that the team doesn’t have to ramp up new working relationships for each project.
You also benefit from working on one thing at a time. That makes it easier to track how much effort has actually gone into a project. When you multitask—working on a major project but also being pulled off onto unplanned work that pops up—you have a harder time figuring how much of your effort went toward that major project. Rarely do people keep accurate notes on how much they worked on one project versus other tasks. In fact, that’s quite hard to do in knowledge work like software development. How do you keep track of what problem you’re mulling over from hour to hour? And when you pay more attention to timekeeping, it distracts you and compounds the problem you’re working to solve.
So, while estimating future work based on past experience is simple, it’s still not always easy. We can make our job easier by changing how we arrange the work (see Ordering the Parts) and how we approach it. There’s advantage in doing so, not only in easier estimation but in being more productive at accomplishing our projects, too.
