19

I was presented with a new problem recently, to provide an estimate for a project in which I must use a framework (and potentially bits of another framework) that I am unfamiliar with. It's much easier for me to provide estimates when I'm at liberty to use what I'm familiar with, but it was as though a crippling paralysis by analysis had kicked in when an estimate was requested for work in unfamiliar territory.

My solution, in retrospect, was wrong. I merely began working.

How might I better estimate projects and tasks when I am required to work with unfamiliar languages/technologies/frameworks?

Improve this question
3
  • 2
    Giving an estimate on something you have never done is, in all practicality, impossible to do with any precision. I recently gave this analogy when asked how long something would take when there were a lot of unknowns: "Imagine you are walking out in the countryside at night. It is pitch black. You need to walk one mile overland. You know which direction you need to go, but you only have a lantern that illuminates ten feet. You have no idea what lies ahead of you: field, river, mountain. Given this, you can make educated guesses, but ultimately you are subject to things outside your control"
    – Nemi
    Jun 15, 2011 at 21:45
  • This also depends on the purpose of the estimate. Are you estimating for most likely case? Worst case? Are there hard deadlines involved?
    – David Thornley
    Jun 15, 2011 at 21:47
  • @David I believe this would be a "most likely" case.
    – Sampson
    Jun 15, 2011 at 22:25

3 Answers 3

Reset to default
18

The standard answer from the agile textbook is to perform a spike. A spike is a time-boxed task to explore the unknown, so that at the end you have (hopefully) sufficient information to provide a useful estimate or you have a better idea of how much more time you'll need to get to that point.

Spikes can last anywhere from 1 hour to several days or even longer. Since they are time-boxed, there is no risk involved for either party, and the expenditure is strictly limited.

Ideally during the spike you would identify a few simple things that needed to be achieved with this new framework and set about very simplistic solutions using it. As you go along, you learn, and that's what spikes are all about.

Improve this answer
2
  • Maybe it's a good idea to add that "spike" is terminology from Scrum.
    – Jesper
    Jun 15, 2011 at 13:50
  • 1
    Sounds like a good approach. In my particular case, my "spike" consisted of the project itself. It seemed a valuable use of my time to actually use the task as my gateway to familiarity rather than some unrelated task.
    – Sampson
    Jun 15, 2011 at 15:27
10

The classic way of doing this is by refinement. At the first planning meeting you say;

"I have no idea - we are basically doing software research here. However, I will have a better estimate by the next meeting, in a months time"

Then you go away and do the research. Next meeting:

"It looks like it will take anything from two to 4 quarters. We are going to build a prototype which will let us refine figures further".

Next meeting:

"The prototype was easier to build than we thought. It looks like we can do it in 2 quarters, plus or minus a month."

and so on. At each stage, the business has the option of canning the project, or letting it continue, getting better and better estimates of the completion date as it does.

This is described very well in Steve McConnell's great book Rapid Development, which deserves to be far better known. Certainly it is far superior to any of the books on "agile" I have read.

Improve this answer
1
  • +1 Thank you for the insight, @Neil. I'll look into the book suggestion as well.
    – Sampson
    Jun 15, 2011 at 15:28
2

You can do research and still come up with wrong estimates. See Large Limits to Software Estimation by J. P. Lewis, and the accompanying material Mathematical Limits to Software Estimation. I'm not saying that you shouldn't bother to estimate or to research, just that you can't make an objectively accurate estimate, and you need to say this along with whatever estimate you arrive at.

Improve this answer
1
  • 3
    Estimates are by definition inaccurate, and it seems that many managers and/or customers struggle with this reality.
    – wolfgangsz
    Jun 15, 2011 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.