Intro

You can find here a definition of an estimation. I’m not going over this.

By formal estimations I mean the ones widely known, documented, and discussed in software engineering, such as time and story points.

I don’t know if “formal estimations” is an accurate term. Simply “Estimations fail”  sounds too much like a clickbait title to me and I want to avoid that. This is also why the title is so long.

The problem

Why?

Why formal estimations don’t work: because of people. I am not saying the estimation methodologies themselves are totally bad. How people use them is the issue: managers just want nice numbers to report to higher managers, and engineers don’t know how to assess work.

Not to go into the old “story points do not include time, they help you find the time” topic. Story points are about… the story. Not about the person. End of… story. And not to mention that estimations are approximations, not hard limits.

They worked once for me

I worked only in one team where estimations in story points (and the whole Scrum methodology) really worked with good effects on both the team and the client.

We were a self-organized team with no managers. And it worked because 90% of the team had the same mindset (from young graduates at their first job to people close to their forties).

Other than this case, I never, ever had a successful time with this.

The solution that works for me

On the other hand, I use another way to estimate, which worked for me. I haven’t tested it enough to generalize. I used it several times and everybody was happy: we delivered without pressure.

Informal estimations

In the lack of other ideas, I will call this method “informal estimations”. I did this by pragmatically analyzing the goals to achieve. And not by “finger in the air” or “educated guess” just to say so numbers. I’m not educated. I don’t have formal education in software engineering.

It starts with managers asking “Can we deliver these topics during a release?”. Sometimes before the release, and other times after the release starts (this second case will often happen).

And I always say, “Give me time and I’ll come back with an answer we can rely on”.

The good managers give you a reasonable and negotiated amount of time.

The bad managers don’t want this, they want any numbers.

The ugly managers are better with their cameras turned off.

What exactly do I do

besides bad jokes that interrupt the flow? I

• • understand the team’s abilities to deliver. If it’s a new team. Otherwise, this step is already done.
  • understand the what. I must know what the team needs to deliver. I had a deal with one of the good managers: You tell me what you need (give me time to understand it and I will even help you define it if necessary) and I will find the how, and do it.
  • identify unknown things and whether they can be safely postponed.
  • test technical ideas just to the level that helps me understand the complexity and possible missing pieces (this step is very important to me).
  • present the plan, the risks, the good case, the bad case, and the recommendations.

With all of those, I can talk with you about time and complexity in a more confident way.

Late TLDR

Trust your engineers and give them time (negotiated) to find the real answers to your needs. And this will save you time.