Relative Estimation

Relative estimation is the process of estimating task completion in Scrum and Agile practices, not by units of time, but using relative measurement units.

1. Relative estimations in modern product development
2. 30 hours for one task or "L" time for development?
3. The Story points concept
   1. Relative development time comes into conflict with traditional project management practices
4. Relativity and product development
   1. Recommendation for using relative estimation

Each team working on a product or project, regardless of its methodology or operating framework, often estimates the time for task development.

Many teams around the world, especially following traditional Waterfall project management methodologies, use an exactly fixed time to estimate the period required to develop tasks.

Relative estimations in modern product development

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 have an exact budget and working hours.

Slowly and with difficulty, many businesses around the world suffer inaccuracies and blame their project managers. Project managers on their end criticize 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.

Instead of giving an exact amount of time to a single task or User Story, for example “1 day’’, you should use another type of time estimate called T-shirt sizing of tasks. This approach has the same size guide as the one of clothes - S, M, L, XL.

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 and User Stories are different things. This is because tasks are based on 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 product’s users.

Fibonacci numbers are often used as the standard for Story Points, which are used for work sizing:

1, 2, 3, 5, 8, 13, 21

If a project manager listed the task "Creating a Product On/Off Button" and it 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 to 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.

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 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, because it doesn’t work with precise time and cost estimates, which can be challenging for the senior management.

Agile approaches can be described as a great convenience for the Agile teams, but an inconvenience for the project clients and the senior management.

The Agile product management and project management community can now be said to have "proven" the convenience of Agile approaches to time estimation through relative units.

The lack of precision in the calculations is compensated by the sponsors, investors, and clients. They are increasingly adopting these flexible approaches and embracing the idea that they do not need to 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 ready" and is usable, stakeholders and sponsors may, at some point, decide to stop developing 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 just about ready, and the amount spent is about $ 1 million, there is no problem with discontinuing the development. Any improvements and new ideas can always be implemented later.

Recommendation for using relative estimation

When estimating time using relative units, we recommend applying numerical values ​​(1, 2, 3, 5, 8, etc.), especially when planning and estimating development time for more extended periods.

The following issues related to chapter "Relative Estimation" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of October 5, 2024, 1:05 am