-2

We had a discussion about the real value of effort estimation (EE) for SW development tasks, and I like to get some feedback from the community.

The major questions in hand are:

  • Should R&D team provide effort estimation to R&D tasks?
  • Can you learn and get better at EE, by extrapolating from task A's EE vs. actual development time, to task B's EE?

The people who support EE (and answer "yes" to the above questions) give these reasons:

  • you must have some kind of EE in order to plan the upcoming tasks / sprints

  • if you know task is small / big, you can decide if you like to develop it or not

  • if you estimate task A in X and it took 3X, you will be able to better extrapolate the estimation of task B and improve your velocity / accuracy / ...
  • A developer should have some kind of time frame for the task he/she is working on

The people who doesn't support EE (and answer "no" to the above questions) give these reasons:

  • Almost every EE is a pure guess. There will be hardly a relation between the EE and the reality.

  • Development tasks are usually very unique and you can't really extrapolate from task A's EE to task B's EE.

  • If a task is needed, it should be prioritized and done, regardless of the time it will take.

  • EE are quickly turned into commitment and blames. "you SAID it will take 1 week, but it took 1 day / 1 month"

  • The only department in the organization that is asked to provide EE is R&D. Usually, product are not EE the time it will take them to write the spec.

  • EE seems to be another way of saying "R&D are a group of slackers and only if we give EE, they will finish the tasks in reasonable time"

I'm not sure there is a right / wrong answer to these questions, but I like to get some feedback from the community.

1

Should R&D team provide effort estimation to R&D tasks?

Yes, it seems to me like a natural part of the process of problem decomposition.

Can you learn and get better at EE, by extrapolating from task A's EE vs. actual development time...

Yes, every developer that thinks about problems and how they decompose can get better at doing this.

If we don't practice problem decomposition and estimation, we won't get better at it.  Each developer that makes an estimate might keep a log or journal regarding what they underestimated: whether things were missed in problem decomposition, problem decomposition didn't go deep enough, or, harder than expected (external API poorly documented/understood, new technology with steeper learning curve), or, maybe, process/methodology issues, skill gap on the team, lack of equipment, technical debt (spaghetti code), insufficient regression tests, etc..  Doing estimates — and tracking how we do/did and why — represents an opportunity: grist for the mill of continuous improvement.  Learnings can be shared in the retrospectives!

...by extrapolating from task A's EE vs. actual development time, to task B's EE?

Some developers are much better at this than others (and some much worse), so there is lots of variance in the quality of these estimates.  Due to this reality, we really shouldn't expect to be able to infer something from A's estimation accuracy to B's estimation accuracy.  At best, we improve each individuals accuracy, and the team leader can get a notion of individual accuracy and how to blend the estimates together.

Estimates are educated guesses.  No one should take an estimate as a guarantee or commitment -- it is an estimate! If someone wants a commitment, let's not use the word estimate.

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.