How often do you, as a Scrum Master or Agile coach, face the problem of estimating tasks in a Scrum team? I regularly run across this problem when launching new teams.

Estimating the time required to complete a task is simultaneously a very simple and very complex, and sometimes very risky task that all development teams face.

Urgent meetings, work emails and messengers complicate the already complex development process, making the perfect “hours” imagined weakly useful for a Gantt chart.

So what can we do in this case? A relative estimation can help us. Instead of estimating the time required to complete a task (days, hours, minutes), we can estimate the effort required to solve that task.

In this case we should take into account all factors that can affect:

• the volume of required work;
• the technical complexity of the task;
• possible risks and uncertainty in the requirements.

A relative estimation in Story Points is better than an exact estimation in days because it allows you to take into account different factors that can affect the duration of task completion. Unlike an exact estimation in days, which can be inaccurate due to unexpected problems or delays, a relative estimation in Story Points allows you to take into account the complexity of the task, uncertainty, and other factors that can affect the time required. Moreover, it is not tied to a specific time, which allows the Scrum team to work more flexibly and quickly respond to changes in the work process.

How can we do it? Here are the steps:

1. Start by defining the estimation scale. Fibonacci numbers are usually used, such as 1, 2, 3, 5, 8, 13, 21, etc.
2. Define what will be the basic task with an estimate of 1 story point. This can be, for example, a task to write a single function.
3. Define what will be the task with an estimate of 5 story points. This can be, for example, a task to write a small module or functionality.
4. Define what will be the task with an estimate of 8 story points. This can be, for example, a task to refactor a large module or write a medium-sized module.
5. Define what will be the task with an estimate of 13 story points. This can be, for example, a task to write a large module or functionality that will take several days.
6. Define what will be the task with an estimate of 21 story points. This can be, for example, a task to write a complex algorithm or implement a large new functionality that will take several weeks.
7. Before starting work, each team member should estimate the tasks in story points. This can be done by voting or individually.
8. After all tasks are estimated, the team should discuss the estimates and come to a common understanding. If the estimates differ too much, the task should be re-estimated.

Tasks are estimated relative to each other, creating a universal estimation scale that is independent of the estimator’s experience. Even if the responsible person for a task changes, its estimate remains unchanged, and new tasks can be estimated relative to this scale.

For example, a task to create a new page on the site can be estimated as 8 story points, a task to add new functionality can be estimated as 13, and a task to optimize performance can be estimated as 21. Thus, the Scrum team can more accurately estimate the complexity of tasks and take into account various factors that can affect their completion time.

You can use any scale to estimate tasks. The most common are Fibonacci numbers, but some Scrum teams use an alternative estimation scale. The most common are estimates in T-shirts, dogs (and other animals), where the complexity of the task is indicated by the size of the T-shirt (S, M, L, XL), the breed of the dog (Chihuahua, Pug, Dog), birds (kiwi, canary, sparrow, crow, eagle), etc. Thus, Scrum teams further abstract themselves from the numerical representation of the estimate, which in some cases may be tempting to translate into a time estimate.

If I see and feel a lack of understanding in the Scrum team about what relative estimation is and how to use it, I try to use metaphors to explain it. Here are some of them:

• Car journey: 1-point tasks are short trips, 5-point tasks are long trips, 13-point tasks are trips to the other end of the country, and 21-point tasks are trips abroad.
• Card games: 1-point tasks are cards that can be easily discarded, 5-point tasks are cards that require some strategy, 13-point tasks are cards that are very difficult to win, and 21-point tasks are cards that require luck and certain skills.
• Mountain climbing: 1-point tasks are easy climbs on hills, 5-point tasks are climbs on medium difficulty mountains, 13-point tasks are climbs on high mountains, and 21-point tasks are extreme and dangerous climbs to mountain peaks.

Using metaphors can help the team better understand how to estimate tasks and which tasks are more difficult and require more time and resources to complete.

One of the biggest mistakes you can make when estimating tasks is to do it on your own without asking for the opinions of Scrum team members. Maybe they have their own opinion on the matter? Want to add support for a new browser? What does QA think about it?

People are the most important resource for estimation. They can see what you don’t.

Relative task estimation in story points allows for a more accurate assessment of task complexity and takes into account various factors that may affect their completion time.

Please share your thoughts on this topic, I’ll be happy to talk about it, it’s not an easy point to decude what is better to estimate in Story Points or in Days.

Do not hesitate to contact me on Telegram or at LinkedIn – just click one of these words.