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

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

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 2

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.