How to outsmart peers in estimation - PERT

Most of us will do estimation as part of the job in building software.

Estimation is not just limited to the job, it’s happening in our life as well.

When your mom or spouse asks: when you’ll reach home — you’re mentioning a time based on looking into traffic on road; THAT’S THE ESTIMATE

Why does the estimation fail?

The estimation fails when there is a major difference between the actual time and estimated time.

Let’s say you are building a feature in the software.

You are estimating it to complete it in 5 days.

  • Estimate fails if it takes 10 days
  • At the same time, estimate fails if you complete in 2 days.

Why overestimate or underestimate?

An estimate should be realistic than an imaginary one.

We should hide behind overestimation or breaking the head with underestimation.

While estimating, one should consider all the internal and external factors to be considered in the part of the process.

What if I missed the deadline even after proper estimation?

Estimation is a skill that makes you feel perfect.

It like machine learning, you will keep on learning by doing multiple iterations.

But each iteration should bring the results better compared to the earlier one. 

How can I estimate better?

Yes, that’s the question we trying to discuss now.

Earlier, in one of the projects I have worked — we have experimented PERT principle to estimate our tasks.

PERT — Project Evaluation and Review Technique

I usually call it with another term – 3 point estimation, because it sounds cooler than the previous one.

Short story

PERT is an estimation technique that helps you calculate the estimate by considering the uncertainties that may happen in the tasks.

So one should bring a 3 estimation for one single task. Let’s see that in detail in the long story. 

Long story

For every task, one should prepare 3 estimates by considering all the risks and uncertainties that may occur.

And using a weighted average of that three numbers to come up with a final estimate.

Pessimistic (P) —  when everything goes wrong

Optimistic (O) — when everything goes right

Most likely (M) — common problems and difficulties — similar to life 🤔

Mostly these estimated are measured in hours or days(6 hours a day). So one should prepare 3 estimates for all the above-mentioned cases.

The program (or project) evaluation and review technique (PERT) is a statistical tool used in project management, which was designed to analyze and represent the tasks involved in completing a given project.

Wikipedia says

Process of estimation

Let’s say, I’m working on the task to build a console application to do some operations.

Now I need to go through the requirements and check the technical impediments in it and decide the workflow. And the come up with these 3 estimates like

If everything goes wrong; Pessimistic — I will complete the task in 8 hours

If everything goes right; Optimistic — I will complete the task in 3 hours

If I have some real problem; Most likely— I will complete the task in 5 hours

That’s it. They can start and continue their work in full swing.

From a project management view

I manage this project and I got three estimates for one single task.

Which one I should track now?

And how can I estimate the overall timeline of the project?

The answer is — we have formula now 🤣

Don’t scare! I do scare when I learned it first. But it’s straight forward, nothing to do with algebra or integral calculus.

The resulting PERT estimate is calculated as 

(O + 4M + P)/6

This is called a “weighted average” since the most likely estimate is weighted four times as much as the other two values. You’ll notice that the final PERT estimate is moved slightly toward either the optimistic or pessimistic value – depending on which one is furthest from the most likely.

Estimation is a skill that makes you feel perfect.

It like machine learning, you will keep on learning by doing multiple iterations.

But each iteration should bring the results better compared to the earlier one.

Try out and leave your feedback in comment section. 

Credits:

Photo by Kelly Sikkema on Unsplash

Funny Excuses that Devs Give

Devs are very brilliant and also they come up with super weird reasons when you catch a bug in their work. I’m a dev too and it was absolutely hilarious to see that I myself use the same excuses sometimes. I came across a meme and I forgot to screenshot it. I remember a few points from it. If you are a web dev, I’m sure you could relate to most of these excuses. Give it a read also a thumbs up if you could relate to any one of these points 🙂

  • It worked yesterday – Yeah, it was the compilers birthday yesterday and hence it compiled the code perfectly. Today it’s not in the mood to compile and hence it is throwing the error. Maybe you should try running the program when the compiler is in good mood.
  • Caching – Did you hard refresh? Did you clear your cache? I think the cache in your browser can’t be cleared, please use a different computer. Let me clean your cache, I’m an expert in clearing. I think the program is cached in the cloud, let me clear that as well.
  • That is weird! – Yes, that’s weird, you expected it to run, but when the QA runs it, it becomes weird. Guess your program is allergic to other people who wanted to see your code working.
  • How is that possible?? It never occurred to me – Exactly, How is that possible?
  • That is an issue with the 3rd party library that we are using – Lemme raise an issue in GitHub. Hopefully they will fix this issue within this year until then we’ll push this bug to the backlog.
  • What is the version of Chrome that you are using? Is it v79.0.3945.117? – No, It’s v79.0.3945.116. That’s exactly why you are getting this error. Could you please update your chrome?
  • I’ve not touched the code in weeks – Yeah, it could be some junior dev trying to figure out what exactly this piece of code does.
  • Did you restart your computer? – Bugs get accumulated if you don’t restart your computer everyday. So just restart and run the program. The error would be resolved (And most of the time it works!! Don’t know how.. )
  • Even-though it doesn’t work, how does the UI feel? – Like crap 🙂
  • The user wouldn’t do it that way – You QA people how do you find some creepy steps to reproduce the bug. Once I had a bug reported that occurs only when you perform certain steps after 37 seconds (seriously??).
  • This is very minor, the user wouldn’t even notice it – Absolutely yes, the user won’t notice if the login page doesn’t show up 🙂
  • Finally, the most used excuse – It works on my machine!! – Yeah, we’ll ship your machine along with the product so that there is no error thrown.

Those were the most common excuses that a dev would give to the QA or the manager. Hope that most of us would have used these or heard people using these. If yes, hit like, share it with your fellow colleagues who give excuses like these. For more tech related posts follow this blog. This is SamuelLawrentz, do connect with me on LinkedIn for more updates.

Happy Coding!