Relative Estimation

in Agile Project Management



By Arvind Mundra

Philadelphia, PA, USA


As they say that life is a journey and most (if not all) value should be derived while you are traveling (or alive).

I want to propose a similar perspective of relative estimation in Agile Project Management. Many times (if not most), the relative estimation is viewed and conducted as if it is a sprint task by itself, barely touching upon the productive side of this journey. If it is performed as a journey to understand the requirements clearly, be creative and bring collective wisdom and knowledge into solution design, and align on optimal solution efficiently, then a couple of hours spent on estimation each sprint would not feel a waste of time. In fact, the time spent on this journey could be the most value adding time of team’s calendar.

As part of many years of Agile coaching and project management, I have come across so many well-intentioned people with valid question – “Why do we need to do estimation?”

Let me give a not-so-simple answer – Why does the Sun need to shine if we were to get the rain?

My sincere apology – I know that it is rude and unprofessional to answer a question with a question but sometimes a pointed question may prod us to find answers within, which is way better than the answers we seek outside. The answers that one finds within come with inherent peace and self-biased acceptance. That may not always be true of the answers we seek from outside.

Philosophy aside, let me connect the dots of this analogy. Just like how the Sun activates the process of evaporation and hence we (or someone somewhere) would get rain, the estimation process activates the process of better understanding and associating and refining, and clarifying and aligning to the requirements so that we (or some customer somewhere) would get the intended value of our product/service.

So how do we bring this new perspective to fruition?

Typically, I recommend three aspects of requirements (user story) to be considered – Doubt, Difficulty, and Duration. These 3Ds provide a good structure to evaluate a particular user story to the base user story. If the team does not have clarity in understanding the user story, the estimate should tilt to higher side. If team is venturing into a new area of development or working with new technology or working with multiple internal and external dependencies, then the user story should be estimated as bigger for the reason of difficulty. The third D brings in the experience into play that development of certain types take little or greater efforts and the user story can be estimated accordingly.

This structure of 3D is neither comprehensive nor was it meant to be but provides a simple, non-jargonized way of evaluating the user stories and sizing them to develop a guideline on time.

Here is a summary of the benefits of (Relative) Estimation in Agile Framework:


To read entire article, click here


How to cite this article:  Mundra, A. (2018). Relative Estimation in Agile Project Management, PM World Journal, Volume VII, Issue XI – November. Available online at https://pmworldjournal.net/wp-content/uploads/2018/11/pmwj76-Nov2018-Mundra-relative-estimation-in-agile-project-management.pdf


About the Author

Arvind Mundra

Philadelphia, PA, USA



Arvind Mundra has been working Agile Project Management for last 20 years in various roles. After spending 6 years as C++ developer, Arvind became interested in aligning project management to the maximum value creation from a software development team’s work. For last many years, Arvind has focused on training software development teams on Agile Project Management and coaching them to build the self-sustaining discipline.

Arvind has gone through multiple certifications from both PMI and Scrum Alliance and has contributed to the pilot program of PMI-ACP certification and has been active in local Agile user groups.

Arvind can be contacted at [email protected]