Agile Scrum Software Engineering

Story Point Estimation: Assumption of Assumption

Estimation is quite a weird term and has two different meanings in practice. Yes, if you ask someone the meaning then you get a dictionary term answer. You will be assured on your understanding and that’s an assumption. That won’t be the case if you approach him with the same definition when you are given an estimate to deliver something. He would expect to deliver by the effort quoted. If you find someone who goes by definition, take a selfie. He is just next to the god 🙂

None of the estimation techniques would help to predict the time of delivery if you measure it in absolute terms. That’s because the ‘atom’ of any estimation technique is YOUR ASSUMPTION

We all pretend to believe that the estimation techniques would help to predict and measure. The success of the technique is presumed by conveniently ignoring those few hours of additional sweat.

But we deal with humans and they have emotions like expectation, trust, greedy to derive more value than agreed, cascading commitments, etc., Connecting both ends by focusing on task delivery leads to compromise. Hence agile paves a way to deal with it.

Agile asks us to treat estimation a level above by knowing the struggle in definition vs reality. Agile advocates to focus on value delivery than task completion. 

“Agile estimation is an approximation of the time in an assumed effort”

Story Point Estimation (incl. poker, t-shirt, etc.,) demands the stakeholders to understand and acknowledge estimation is an assumption and approximation. As an outcome of this, Agile warrants mindset change and a cultural shift. 

Agile advocates not to cook in a hurry but suggest to prepare for a feast. A hungry stomach may look for turn around but won’t get a chef’s special. Nothing wrong in feeding a hungry, if they don’t want feast.

Author

KR Kaleraj