Relative estimation is the process of estimating task completion in Scrum and Agile practices, not by units of time, but using relative measurement units.
Each team working on a product or project, regardless of its methodology or operating framework, often estimated the time for task development.
Many teams around the world, especially following traditional Waterfall project management methodologies, use the exact fixed time to estimate the time required to develop tasks.
Modern product development uses relative estimation
Modern product development and project management have, to some extent, found that when tasks are estimated using fixed time, these estimates often turn out to be inaccurate.
Product management has developed more flexible approaches to time estimation. Agile-oriented systems have demonstrated an advantage over fixed-time estimates, in which each task and every effort must be estimated with the exact amount of money and hours worked.
Slowly and difficultly, many businesses around the world suffered inaccuracies and blamed their project managers. Project managers criticized the development teams.
This inaccurate approach often leads to stress and failed planning.
Scrum teams are less likely to encounter such problems because they rarely use task scheduling, indicating exact development time, measured in days, hours, or minutes.
30 hours for one task or "L" time for development?
Relatively estimating the time to complete tasks is an approach that can reduce stress and give you a general idea of time, instead of estimating with precision up to an hour and a day.
Instead of saving for a single task or User Story, it takes development time of "1 day," you are reporting development time that does not relate to "hourly" time. For example, you specify XL.
This approach is called T-shirt sizing of tasks, just as your clothes can hold the size of S, M, L, XL, etc.
When gathering with your teams and conducting a Sprint Planning meeting to estimate the time needed for your upcoming work, set aside a time that is measurable with relative value for each task.
Some teams prefer T-shirt sizes. Others prefer the so-called "Story Points", which is a time measurement system using numerical values.
The Story points concept
"Story Points" is derived from the concept of "User Story". We mentioned User Stories many times. In project management, tasks are usually called "tasks". In product management and Scrum practices, however, tasks are often called User Story, although "tasks" is not the right word. Instead, tasks are created by different "fictional" user stories.
The entire product that your development team is working on is told in the form of user stories. Instead of describing the scope of the project and writing huge documents of requirements and quality, the Product Owner role simply "tells stories" of all the work that needs to be done. These "stories" are told from the point of view of the users of the product.
If a project manager listed the task "Creating a Product On/Off Button" that had an estimated development time of 1 day, the Product Manager or the Product Owner would write a User Story with the content "As a product user, I need turn on and off the product. " The Product Manager or the Product Owner will then consult with the technical teams, and they together estimate the development time required as Story Points 3.
Fibonacci numbers are used as the standard for Story Points:
1, 2, 3, 5, 8, 13, 21
With these principles of "sizing" work, a User Story that will take very insignificant development time can be written to take "1" work time or "S" work time.
You can define a more significant task as "5" or "L", for example. A huge task may need time to develop a "21" or an "XL".
Relative development time comes into conflict with traditional project management practices
Relative development time comes into conflict with traditional project management practices in general, as it can be difficult for your senior management to calculate precise project completion time. Calculating the exact costs is also difficult.
These approaches can be described as a great convenience for the Agile teams, but an inconvenience for the project clients and the senior management.
The product management and project management community can now be said to have "proven" the convenience of Agile's approaches to estimating time through relative units.
The lack of precision in the calculations, informally, can be said to be "offset by tolerance" of sponsors, investors, and clients. They are increasingly adopting these flexible approaches and embracing the idea that they do not know precisely how much their project is going to cost, and they are also starting to think in relative terms. Half a million, one million, two million.
Relativity and product development
Since relativity is the approach of Agile product management disciplines, there is always one fundamental rule and practice in those methods.
Not everything that is planned as tasks is actually developed and implemented in the project. When your product is already "kind of a ready" and is usable, stakeholders and sponsors may, at some point, decide to stop growing it.
Discontinuing development, at some point, is a way to compensate for the lack of accuracy in cost estimation. When a product can be considered "relatively ready", it is not necessary for investors or customers to expect all User Stories that are on the Product Backlog list to be completed. If the project is planned for $ 1 million and if the product is almost ready by now, and the amount spent is about $ 1 million, there is no problem with discontinuing the development. Any improvements and new ideas can always be done later.
Recommendation for using relative estimation
When estimating time using relative measurement, we recommend applying numerical values (1, 2, 3, 5, 8, etc.), because planning and estimating development time for more extended periods is easier.