One of the activities that those of us working in the IT industry face on a regular basis is coming up with an estimate for a task, activity or deliverable we’ve been assigned. Whether it be completing a piece of code, executing a test case, completing a series of requirements gathering sessions, writing a business case and so on, we all are expected to give our superiors a sense of how much effort is required and/or how long it will take.
Estimates can vary in formality and complexity. The estimate you give a team lead that just drops by your cubicle asking how long your most recent task will take is different than supplying numbers for a detailed multi-year project plan. At its simplest, an estimate is just a number with no caveats, reasoning or justification behind it. At its most complicated, it is a series of detailed spreadsheets with complex calculations, pages of assumptions, qualified risks and multiple constraints identified.
An inaccurate estimate can lead to a number of problems: uncertainty, delay and, worst of all, a loss of trust by those you report to. So, how do you deliver good and realistic estimates that stand up to scrutiny? This post aims to provide you with some tools to achieve just that.
The two most basic elements of an estimate are effort and duration, usually expressed in hours, days or weeks. As a basic definition, effort is how much work is involved and duration is how long that work will take to complete. There are a number of other factors that can come into play that aren’t always stated along with an estimate. These might be commonly assumed between the parties, such as each day consists of seven hours of working time. Other factors include relative priority, dependencies on other people, tasks or deliverables, outstanding questions that may change the scope of the task, and the skill level of the resources who will be doing the work.
How and when to include these various factors into an estimate can be difficult. Generally, in an environment where both the provider of the estimate and the person asking for it have a shared understanding of the above factors, they often go unsaid. If the estimates are being used for a formal proposal, for example, you likely want to list and qualify each one. At a minimum, I would never recommend giving an estimate without at least signifying whether it is a duration or effort-based estimate. This eliminates any confusion as to when you were expected to have something completed by.
So, what should go into that initial number that comes to mind when someone asks you for an estimate? I know this happens to me: someone asks a question and a number just pops into mind. But how do you know you are close? Each of us has experiences that we draw upon to complete these estimates. Maybe we’ve done this exact task before or perhaps we’ve done something like it that can be drawn from. Perhaps we know someone else who has done this and how long it has taken them. Let’s call this initial estimate, free of any conditions, value X.
At this point, many people will just give that value, X, to their superior as the estimate and be done with it. But what if you feel the need to include several different factors that might change the overall number? For myself, I have found that writing it out helps me make sure I am coming up with something that I am comfortable with and is realistic. Of course, this assumes you are given the time to think things through.
To make a real example of it, let’s say that we have a PM who asks us to estimate doing task X a total of 10 times before the goal will be reached. Let’s also say that two different resources will be doing X a number of times and that Resource 1 delivers at a rate of 50% faster than Resource 2. To further complicate matters, Resources 1 and 2 both work Monday to Friday, can expect six hours of dedicated time to this task for the duration, but will lose two days during whatever period it is determined to take for some scheduled training. As a final assumption, we’ll say that when a resource is working on X, they can’t also be working on the next X (i.e., each unit of work cannot overlap).
With an example like this, I find myself back in junior high doing algebra.
Effort = Total Work / Total Resources
Effort = (X x 10) / (1 + 0.667)
Let’s say that X = 32 hours so we have 320 / 1.667 = 191.96 or 192 hours of effort to complete X 10 times with Resources 1 and 2. As another tip, I suggest whenever you end up with a decimal in your estimates, always round up. Don’t round down or truncate.
Happy with our estimate, we might go tell our PM, but we know they are likely to turn around and ask how long it will actually take. Back to the chalkboard.
Factors: 5 days per week, 6 hours per day, lose 2 days due to training
192 hrs / 6 hrs per day = 32 days + 2 days lost = 34 days
34 days / 5 days per week = 6 weeks + 4 days (or, rounded up, 7 weeks)
Seven weeks. Now we’ve got an effort (192 hours or 32 days) and a duration (seven weeks). We might want to tell the PM at this point that we have a pretty solid estimate, but I like to check my numbers for reasonableness. When you use a bunch of mathematical factors, things can quickly balloon out of control if you don’t make sure the factors actually reflect reality. Does the total “feel” right to you? Should you maybe run it past someone else to see?
If you’re still confident in the numbers and are about to send away that estimate, you may want to include the final factor, the “sh*t happens” factor: contingency. This is an overall factor, generally expressed in percent, that can be added to your estimate to give a little wiggle room. Common values include 10, 20 or 25%. My advice at this point is to talk with the person you are giving the estimates to.
It turns out that many of the people we give estimates to also have their own factors just waiting to be applied to whatever number you are about to give them. They may have an automatic contingency, a built in “management” factor, or may simply just double every number you give them as a butt-covering tactic. They might base this on the details you used to come up with your estimate if you share them or they might apply it regardless.
Now you’ve given that estimate and it’s been fired up the food chain. So, what happens if you are called out on your estimates? How do you explain yourself so that they understand you didn’t just make that number up in hopes they would leave you alone and go bother your co-workers? That’s where a trail of deduction, hopefully building from commonly understood components, becomes your best friend. It doesn’t have to look like a complicated mathematical equation, as long as it is logical and clear. Strangely enough, the CIO isn’t always going to believe you when you say “Just trust me.”
I hope this takes some of the magic out of giving good estimates you can confidently stand by. I frequently fall back on this type of deduction to determine efforts, resources, work breakdowns, and overall timelines for the work. I also apply it, through a series of questions, to review estimates that are provided to me. When required, I have presented numbers in this fashion to senior management and have never been told that they can’t trust the numbers because they were too detailed.