Agile Estimation — One of the most controversial topics ever. This word — “Agile Estimation” — has become a bane in the IT industry. I see it being bashed on internet and it is causing more confusion and pain amongst people than helping them. But it does not need to be like that.
In this blog I would like to share some perspectives that can help people to get some clarity on
- What is Agile estimation?
- Why do we need Agile estimation?
- How teams do it?
So let me tell you a story.
Years back, I joined as a fresher in a service-based industry. A very typical structure — I was one of the developers in a team of 10 with a Project Manager to whom we all used to report. All the developers were in varying years of experience right from me as a fresher to 10 years; and Project Manager experience of 10 plus years.
I would be given a job or a feature to be developed and my Manager would ask me now and again how much time it will take for me to get it done? And I would have no clue because I really did not understand the scope of work. But because my manager insisted, I would give some estimate and it would always take way more time than I would have estimated. I would be really frustrated and unhappy thinking why my manager keeps asking me about time all the time.
Years went by, I gained experience in different domains and industry. Now I was working for a product-based company. This time too, when I would pick up a feature to be developed, my manager would ask me when the work will be done? Because I had experience, I was more confident on the outcome. Though I understood how complex it is and what was the scope of work, my estimates were just that — estimates. Of course, the type of work that would take me a week to get it done as a fresher would now take me a couple of days. But, an exact timeline was impossible to give as there were always some unknowns.
So what happened? Why the change?
Because I got experience. As I got more experience, I was able to do the same job in less about of time. Does not mean the job became smaller, but my ability to get the solution done improved — the job is still the same.
So if you think from that perspective, a job is like a problem to be solved or a feature to be developed. The actual time it takes to get the solution of the problem may vary on the experience of the person who is solving it, the technical stack, etc. As one gets experience, they may take shorter time to get the solution, does not mean that the problem has changed.
Let me give you another example. We all know Michael Phelps — the Swimming Legend. He participates in 100m, 200m, 400m swimming championships with Butterfly, individual medley, freestyle and backstroke. Let’s take example of 200m. He does not take the same amount of time every time he participates in the 200m championship. Though the distance remains same -200m, his performance varies from time to time, based on how fit he is, his practices, etc. Similarly, the time it takes to cover the same distance of 200m also depends on the style he uses — butterfly, freestyle, etc. The 200m is like the problem, the time it takes to cover that distance and the style he uses is the solution.
We all know that Problem and Solution are two different things, and should be measured differently.
Watch this vlog to understand the difference between problem and solution even better with a few more examples.
Going back to my earlier story — remember those managers who kept asking me about time? Although I thought they were pure evil, there was a purpose behind it. We will explore this purpose in a series of upcoming Vlogs. So hang on!