How to schedule "piece of string" tasks

Question

We have an old database which is used to hold supporting information about the financial system. Most of the actual code in are in Views which consolidate the supporting data with the financial data (held in a different system) into a single table. Some of this View code is very large.

Due to a change in the way financial outcomes are reported, a change is needed to the largest of these views. It is not immediately apparent where this change can be made. However, it is very likely that it's actually quite a small alteration in the actual code.

I have been tasked with "estimating" this work. But this presents me with a problem. To estimate it, I need to work out what needs to be done. This is time consuming as there is no obvious fix - some of the sub-queries need to be split up and investigated to artifice one. Actually making the fix once one is found will probably take no more than a few minutes.

I sometimes call this sort of work "string" work because when asked how long it'll take, the answer is "how long is a piece of string". Almost all the work is in the planning and investigation and it's not clear how much effort that entails.

I find myself in this situation relatively frequently when it comes to bugs and point changes. This poses problems when your manager wants to resource your time or abide by a timeboxed methodology such as Agile. How can you estimate/plan for these sorts of tasks? And if no estimate is possible, is there any value in arguing to management that this kind of work cannot be effectively scheduled?

Answer 1

Characterize the work as research.

Research does not naturally lend itself to estimation, because you know neither the answer nor where the research is going to take you. CERN can give you an estimate of how long it will take to build their next supercollider (though that estimate still contains some unknowns), but not how long it will take to find the God particle.

Make it an opportunity to lower technical debt.

If you can sell the idea that this "research" will yield future dividends in improved maintainability, then you can make an estimation based on the rework required and also provide more attractive deliverables than just "fixing this one obscure bug."

Count lines of code.

You could make a reasonable guess at an estimate by assuming that you will have to review every line of code in this particular module to find the problem, estimating the time it will take (3 to 5 minutes, perhaps) to review each line of code, counting the total lines of code in the module, and multiplying the two numbers for an overall estimate. This is a simple form of cooking the elephant; breaking the problem into smaller pieces makes it easier to estimate.

Answer 2

In my past position my tasks were very similar to your "string" problems, I would't know if the solution was as simple as changing a value in a config file or a half way rewrite of a plate of 8 year old spaghetti code. With my boss we worked out a system that seemed to jive well with everyone.

First, I always responded to time estimates with a range. The low number was what I would expect it to be if everything fell into place like magic. The high number was an educated guess on how long it would take (worse case) based on what I knew of the system and my past experiences there, etc. As a general tip for time estimates, both numbers had a buffer built in because I naturally underestimated things. Also there is a minimum amount of time that anything takes (if you are a full time employee I typically put this at half a day for software tasks and a full day for electrical tasks). Even if it takes 30 minutes to make the software change it will take 2 hours getting all of the project files together and built, an hour to test and check things in, half hour for Joe from accounting to walk by and distract you, etc.

Now if I couldn't deliver those two numbers with any confidence, I'd either widen the upper range to where the estimate was basically useless (might make some people upset but hey, it was the truth) or more commonly I'd be able to estimate how long it will take me to write an estimate. With these string problems I could usually take a glance and if I came out saying "well it'll either be a quick fix or who the hell knows" - I'd usually know enough to say "If you'd like an estimated I need x amount of hours investigating the issue and I'll report back." The people I worked with thought this was reasonable and was our main strategy.

If you happened to find the answer and solve the problem during that investigation period - congratulations, you're a hero, report back with "It was an easy fix and its already done - I just need a few hours to test my solution".
People will be happy. If it's a longer fix, then you can report an estimate that is meaningful to the people who need it to make the decision and you still win.

Answer 3

It is not immediately apparent where this change can be made. However, it is very likely that it's actually quite a small alteration in the actual code.

Then you already have an estimate of the time for the actual code changes, you don't need to know where for that.

This estimate will be wrong only if the "very likely" thing does not happen, and that's OK - it is just an estimate, after all.

To estimate it, I need to work out what needs to be done.

No. Figuring out the details of code changes is not part of estimation.

Simply estimate the time it will take to figure out the details and add it to your estimate for the concrete change. Maybe do some time-boxed initial research if you're unsure.

Of course this assumes an organization that does not react pathologically to estimation errors. If your boss will punish you for making "wrong estimates" occasionally, then you'll have to tell him that the estimation itself takes a long time that is either unspecified or itself estimated very generously.