• Gábor Csepregi

On the Importance of Estimations

We saw in the previous entries how a regular development flow works. It was quite simple to start a project from scratch and deliver the first MVP. We helped ourselves by specifying a scope as narrow as possible so that we were able to cope with it. What’s the technique we used to do so? Of course, estimating.

Let’s imagine you ran out of bread at home, so you send your child to buy one loaf. The shop is 5 minutes away, and it takes at most another 5 minutes to find the bread and pay for it. So, in all with some error added, your child should be home in 20 minutes. He estimates your task to 5 story points, which is the same in his dictionary as getting to the playground to play football with friends.

Great! You give him money and let him go. You’ve been waiting for two hours when you are getting a bit uncomfortable. You don’t want him to feel the pressure. Estimates are just a rough idea not carved in stone. Anything can happen on the way to the shop. So, you wish to hear his side of the story first. You give him a call, and he responds:

“Hi, Dad, I’ve just happened to see a few ducks on the side of the road. They ran away but I know you love them, so I followed to take some nice pictures. That’s when I found a hole in the ground in the park looking like a rabbit hole. So, I investigated further. It turned out to be empty, but hey I finally made it to the other store. I know you like them better because they are not mean like elsewhere. When I looked around, I saw two pencil sharpeners of the type you broke, so picked one. Also, I know you love that smelly cheese. A kind lady asked me to help her with her basket home, so I’m now on the other side of the park but will get home soon. Bye!”

Okay, you think. But you just wanted the bread for breakfast, and now it’s getting closer to lunchtime.

As a manager, how many times have you heard explanations on delayed delivery like above? As a developer, how many times have you done extra work, that you were not asked to do, just because you thought it would be nice?

Any development worth only the loss of time and money that was invested in it until delivered.

I took small research on this topic – googled estimation vs effort – to see what the current hype is. And was shocked by statements like “You don't give promises that are hard to keep”.

When a friend asks you out to lunch, and you respond: “just 10 more minutes”, what do you think you are doing? You make a promise. You estimate.

When you start building a house, would you like the contractors to give you story points, or an estimate on when you can move in?

Why do developers feel they are so special that they don’t need to estimate? Because they actually do it a million times a day. All of them. Just like the rest of the world.

Another blog goes like this: “For example, instead of estimating that Creating a Shopping Cart will take 5 days, you estimate that Creating a Shopping Cart will require a particular number of Story Points.

If you think that “Creating a Shopping Cart” can be estimated as a task, that should raise the red flag. This task is too complex. It consists of at least 20 subtasks, and I doubt it will be done under 20 days if estimated as a whole.

I was involved in a team, where I argued a lot about my visions. One task was planned for a two-week sprint. When I asked what is involved, how we would split it, the answer was, it’s not part of the sprint planning. It was already decided on a refinement session. I wanted to know more, so we broke down the task and it turned out to be a 5-minute change in an API, a 10-minute change in another, a two-hour new feature in a backend process, plus the added unit tests. All this in two weeks.


I’m worried that developers forgot how to plan their work. Or even they are discouraged to hone and build this skill. I truly believe that most software projects could be done half the time, with a quarter of the budget and less hassle in the maintenance phase, if we would spend more time on figuring out what we want to do ahead of carving it into stone of code. I've seen it in practice.

17 views0 comments

Recent Posts

See All