What's the best way to do estimates without spending a lot of time?

Question

Background

My team current is currently in the "bug fixing and polishing" phase of shipping a major rewrite. We still have a large stack of bugs to fix, scheduled against a couple of milestones. We've been asked to come up with estimates, of how much engineering effort is required to fix the bugs for each milestone.

For previous milestones, we've followed the following process:

• Assign the bugs to the people that know the most about that area of the code, and will likely be the one to fix the bug.
• Have each person go through the bugs that are assigned to them, and estimate how long they think it will take to fix the bugs, at an hour-level granularity. If a bug looks like it will potentially take more than a day or two to fix, they break the bug into likely subtasks, and estimate those.
• Total the amount of work assigned to each person for each milestone, and try and balancing things out if people have drastically different amounts of work.
• Multiply each person's total for each milestone by a "padding factor", to account for overly optimistic estimates (we've been using 1.5).
• Take the largest total across the team members for a given release, and make that the time it will take for the team to close the existing bugs.
• Estimate the number of bugs we expect to be created during the time it takes us to reach a particular milestone, and estimate how long on average, we think it will take to close each of these bugs. Add this on to the time to close the existing bugs for each release. This is our final number of the amount of work needed, delivered as a date by which we'll definitely ship that milestone.

This has been fairly accurate (we've come in pretty much spot on on our previous three milestones), but it's rather time consuming.

Current Problem

We've been asked to give estimates of the engineering time for upcoming milestones, but asked not to use the above process because it's too time consuming. Instead, as the tech lead of the team, I've been asked to provide estimates that are less certain, along with a certainty interval (ie, 1 month, plus or minus a week).

My primary estimation experience is with some variation of the method I described above (from a background of freelancing for a number of years). I've found that when I "shoot from the hip" on large tasks, I tend to be way off. I suspect it will be even worse when estimating how long it takes to fix bugs in areas of the code I don't know very well.

What tips, tricks or techniques have you found successful for estimating quickly, without breaking things down into fine grained tasks and estimating them?

Things that are not an option:

• Not giving an estimate - I've tried this, it didn't fly:)
• Picking a number and confidence interval that is ridiculously wide - I've considered this, but I don't think it'll fly either.
• Evidence-base scheduling - We're using JIRA, which doesn't have any evidence-base scheduling tools written for it, and we can't migrate to FogBugz currently (BTW, if someone goes and writes an evidence-based scheduling plugin for JIRA, we would gladly pay for it).

Answer 1

Calculating the variability in your estimate will take longer than calculating your estimate.

Answer 2

The best tip for estimating: round up a heck of a lot.

It sounds like you're already an expert on the topic of estimation, and that you know the limitations of what's possible. It just isn't possible to estimate a task without assessing what needs doing to complete it!

Amount of time assessing is directly proportional to accuracy of estimate. And these things converge at the point when time assessing is so accurate you've solved the task, at that moment, you know exactly how long it takes.

Hmm, sorry, this may not be the answer you wanted to hear... it's just my thoughts on it though.

Answer 3

public static class Time
    {
        /// <summary>
        /// Estimates the hours.
        /// </summary>
        /// <param name="NumberPulledFromAss">The number pulled from ass.</param>
        /// <param name="Priority">The priority.</param>
        /// <param name="Complexity">The complexity.</param>
        /// <returns>
        ///  a number in hours to estimate the time to complete a task.
        /// Hey,  you will be wrong anyway why waste more time than you need?
        /// </returns>
        public static int EstimateHours(int NumberPulledFromAss, int Priority, int Complexity)
        {
            var rand = new Random(NumberPulledFromAss);
            var baseGuess = rand.Next(1, NumberPulledFromAss);
            return (baseGuess + (Priority * Complexity)) * 2;
        }
    }

Answer 4

You've been asking how to produce an estimate and an uncertainty interval. A better way to think of this is to do a worst-case estimate and a best-case estimate. Combine the two to have an estimate range. Well understood issues will naturally be more specific then the estimates for less-understood issues. For example, an estimate that looks like 1.5-2 days is probably for a well understood issue, an estimate that looks like 2-14 days would be typical for an issue not at all understood. Limit the amount of investigation and time spent producing an estimate by allowing for a wider gap between the estimates. This works because its relatively easy to imagine realistic best case and worst case scenarios. When the uncertainty range is more than you're comfortable dealing with in the schedule, then take some time to understood the less understood issues. It may help to break them up.

I usually go for half-day granularity rather than hour granularity in my estimates if the work is expected to take more than a week overall.

Answer 5

1. Be prepared to create a release at any time
2. Have the stake-holders prioritise the work done
3. Work on the highest priority items

Step 1. means you never miss a deadline.

Step 2. is a way of turning the question back on those who are asking you to estimate without spending time estimating.

Edit...

The above doesn't really answer your question, sorry.

The stake holders will want to prioritize work based on how long and expensive each task will be, and you are likely to be asked which of the highest prioritized changes you expect to be able to complete by the next deadline.

My technique that takes the least time is to use three times my impression of how long I think it would take me to do it.

You're looking for something taking longer than that, but not as long as your previous excellent estimates.

You'll still need to look at each bug, even if only to take a guess at whether it is easy, average, or tricky, or 1,2,4,8,16 or 32 hours work.

If you produce some code complexity metrics over your code base (eg cyclomatic complexity), and for each task, take a stab at which two or three portions of that code base will need to be changed the most, then estimate based on the assumption that the less complex portions of code will be quicker to change than the more complex portions. You could come up with some heuristics based on a few of your previous estimates, to use for each bug fix, giving an estimate of the time and variability required.

Answer 6

Your estimates are as accurate as the time you put into them. This time can be physical time breaking down the problem or drawing upon past experiences in areas you're familiar. If this isn't an option the try breaking the bugs/polish down into groups.

1. Trivial fix of a few hours.
2. Up to one day effort.
3. Very complex - one week effort.

Once you have these categorised then you can work out a rough guestimate.

Answer 7

Many hints may be useful in this article on an agile blog: Agile Estimating.

Answer 8

Use Planning Poker, see the answers to How to estimate the length of a programming task

Answer 9

How about:

estimate=(bugs/devs)xdays (xK)

As simple as this is it's actually quite accurate. And can be estimated in 1minute. It's confidence level is less than your detailed method, but I'd recommend you check your data on the last three milestones and check the difference between this quick estimate and your detailed estimate that will give you a "K" value representing your team's constant.

Be surprised.

Answer 10

In simplest terms:

Your Most Absolutely Liberal Estimation * 3 = Your Estimate

The above may look like a joke, but it's not. I've used it many times. Time estimation on software projects of any kind is a game, just like making a deal with a car dealer. That formula will get you something to provide your management in a pinch and give you some room to play with as well.

However, if you're somehow able to get down to the more granular details (which is really the only way you'll be able to be more accurate), Google on Function Point Analysis, sometimes called "Fast Function Point Analysis" or "Fast Function Point Estimation".

Many folks out there have a myriad of spreadsheets, PDF's and the like that can help you estimate as quickly as possible. Check out the spreadsheets first as they'll have formulas built in for you.

Hope this helps!