Skip to main content
Get a FREE
BVOP® Certified Scrum Master trial exam
Join the modern BVOP® Agile teaching $ 0.00 trial exam fee. Free self-study Get a FREE Trial
Scrum Master Certification Get Certified

Relative Estimation

What is relative size estimation in Scrum and Agile?

Share on Linkedin Facebook
What is relative size estimation in Scrum and Agile?

The following article is part of the self-preparation for the modern BVOP® Scrum Master Certification program.

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 July 8, 2020, 4:21 pm

ID Issue Time Category
0 30 hours for one task or "L" time for development? 60 sec SM, PO
1 The Story points concept 60 sec SM, PO
2 Relative estimations in modern product development 60 sec SM, PO
3 Recommendation for using relative estimation 60 sec SM, PO
4 Relative development time comes into conflict with traditional project management practices 60 sec SM, PO
5 Relativity and product development 60 sec SM, PO
Comments of our guests
  1. Anita Weber
    Hello. There is one topic that I have been thinking about lately, and that is precisely the estimation of the time needed to develop the tasks. In short, how can I be sure that my team is not lying to me when estimating development time? I know this may sound lame question, but I am in a position where I would need some real assistance with this issue. Thanks a lot in advance. Regards, Ani
Author

Web site
Your Comment
 

The BVOP Certificates

Certified Chief Executive

The BVOP Chief Executive is the core driver of the Business Value-Oriented Principles and the most advanced figure who has the organization’s best interest.

Get Certificate $1290   $720

Certified Program Director

The BVOP Program Director manages the entire Program Management Office and possesses exceptional expertise and applies strategies.

Get Certificate $720   $490

Certified Agile Director

The BVOP Director is the most advanced and important role inside Agile products and services-based organizations.

Get Certificate $440   $220

Certified Project Manager

The BVOP Project Manager is an advanced and competent business, product, and technical role and a key factor for the success of the projects.

Get Certificate $280   $130

Certified Product Manager

With the advancing design, development, technical, and business knowledge, the BVOP Product Manager is a master role and decision-maker for the products.

Get Certificate $280   $130

Certified Product Owner

Responsible and skilled BVOP Product Owners balance both business and technical needs using Agile approaches and provide business value for products.

Get Certificate $180   $90

Senior Scrum Master Certification

The BVOP Scrum Master role combines skills, Agile thinking, and project management practices to enchant processes, teams, and stakeholders.

Get Certificate $140   $70

Certified Human Resources Manager

People are the greatest assets of any organization. It is important to find a balance between people and organization’s needs.

Get Certificate $140   $70
×
Get the BVOP™ Agile Project Management Certification
$ 0.00 ONLINE Trial Exam