How to estimate tasks without Planning Poker and unnecessary words

Snap effect

Let's look at the anchoring effect in the context of time estimation. Let's imagine that we have assembled a team of 5 people for grooming according to the backlog, within the framework of which tasks are analyzed, discussed and evaluated one by one.

At one point, one of the planning participants expressed the opinion that this feature was small and would require, for example, less than 16 hours to implement.

As a result, all subsequent participants will involuntarily start from this figure and make an assessment based on it. This can be a particularly serious problem if you are the first to express an opinion. authoritarian authoritative participant.

For clarity, consider the following example:

Senior backend developer Nikita is a key team member who worked a miracle in the last sprint and brought complex functionality straight to production without a single bug. However, this time he did not have all the information, in particular, he did not know that integration with external banking services was necessary to implement the new feature.

At the same time, Alina, a Middle backend developer, knows about this, since she was at a meeting with the architect, and initially believed that implementation would require at least 100 hours. Now, after Nikita’s assessment, she begins to hesitate (“Nikita has more experience!”) and gives a number close to Nikita’s – 50 hours.

After a short discussion, Nikita and Alina agree that 40 hours, taking into account integration with banking services, is enough to implement the feature. Nikita is not only a good developer, but also knows how to convince other people well.

As a result, the feature was implemented in 80 hours. And here we have the problem of estimating time – the task is underestimated by 2 times! What if there are a lot of such “mispricing” in the backlog? Deadlines don't creep, they fly!

If the team had used poker planning, then Alina’s estimate of 100 hours would have caused a different course of discussion and would have allowed all team members to see the risks of developing this feature.

Planning Poker price

Despite all the advantages, planning poker has a significant drawback – the time expenditure of many specialists at the same time. After all, to come to a common opinion, you need to:

1. Gather (distract from work) a number of specialists.
2. Find consensus. This rarely happens quickly, especially if all the participants are experienced and have their own opinions.

This is felt most strongly in large teams. I believe that many will agree that reaching consensus between 2-3 participants is much easier than in a group of people of 7 or more people.

If the backlog consists mainly of simple tasks, then the developers' estimates are more likely to coincide, since they are in a narrow range of values. In this case, consensus is relatively easy to achieve even in a large team.

In cases where the backlog consists of non-trivial, complex tasks, or the degree of uncertainty is quite high, the spread in estimates is likely to be significant, and long heated discussions await you.

Note that investing a lot of time here is justified, because you and your team have just identified potential risks. Luckily, you'll be discussing them early in development.

So planning poker is a brilliant tool that's worth a try if you haven't used it before.

And eat the fish and climb the tree!

Let's imagine that the team does not have the opportunity to conduct full-fledged poker planning. However, there is a need to achieve a realistic assessment, taking into account the views of different actors no anchoring effect.

Let's assume that system analysts have already worked on a new epic: they analyzed the requirements and described in detail the tasks for developing REST API methods.

We see that the backlog consists of 14 new tasks, and the team has 3 backend developers: Nikita, Alina and Sergey. We need them to appreciate these tasks.

The next three sections contain the preparatory steps you need to take to ensure that the evaluation process is not time-consuming for you or the developers.

If you wish, you can skip this description and jump straight to the time estimation section. However, understanding how files are organized will allow you to adapt them specifically to your specific needs. For example, add a column for another developer, or add macros and additional formulas that can expand the functionality of the tool.

Preparatory activity 1. Master file with assessments

This file (using Google Sheets as an example) will contain the ratings of all developers in one place.

Main file with grades

Main file with grades

1 – Name of the main file (in our case it is “Summary”).

2 – Sheet name. In cell “B1” duplicate sheet name (this will be useful later for setting up automatic formulas).

3 — The column will contain links to Jira/Trello/Yandex Tracker; upon transition, the developer will be able to study a detailed description of the selected task.

4 – The column contains the name and description of the issue (most often it matches the name of the issue in Jira).

5 – Columns with time estimates from developers, which will be automatically imported from developer files.

6 – Column that will contain the most conservative estimate for the task.

7 — Column with the median estimate of the task.

8 — Column with the average rating of the task.

9 — Column with actual time spent on the task.

Preparatory Activity 2: Developer Assessment Files

For each developer, you need to create separate Google Sheets in which they will provide time estimates.

First of all, let's create and configure a table for Nikita:

Developer ratings file

Developer ratings file

1 – The file name contains the name of the developer.

2 – Sheet name. In cell “B1” duplicate sheet name (this will be useful to us in the future for setting up automatic formulas).

3 – The column will contain links to Jira/Trello/Yandex Tracker, the data will be automatically imported from the main file (our “Summary”).

4 – The column contains the name and description of the task, the data will be automatically imported from the main Summary file.

5 – Column in which the developer will enter an estimate of time in hours.

6 – You need to configure access to the developer file.

Give the developer permission to edit the file. This way, only you and the developer Nikita will have access to the file. And even if you are paranoid, you can definitely guarantee that Alina will not be able to spy on Nikita’s grades. Unless the latter wants to enter into a conspiracy with her, but this is a risk beyond the scope of this article 🙂

Access Settings

Access Settings

Now let's create the same files for Alina and Sergey. The easiest way is to create copies of the files and repeat steps 1 and 6 for Alina and Sergey, that is, rename the file and configure access for them.

Preparatory step 3. Setting up automatic data import

To automatically import data, we will use the function IMPORTRANGE(spreadsheet_url, range_string).

  • spreadsheet_url — a link to another table from which we want to import data.

  • range_string — the range of data in the “SheetName!Range” format that we want to import.

Main File – Automatic Import of Developer Ratings

Synchronizing Time Estimates

Synchronizing Time Estimates

Column with Nikita's ratings (cell C4):

=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1icCY_nHpJMruFQPX0w1gD88G64xK75vK2uYWhD8Nhr4/edit?usp=sharing";$В$1&"!C2:C100")

This formula imports Nikita's time estimates from the range C2:C100 on the Backlog sheet from the Nikita file. Note that the sheet name is listed in cell B1.

Column with Alina's ratings (cell D4):

=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1gtaLDNGvInjfELgPqUDI4t0ZQdSYUVkcTgmriv1Ua_g/edit?usp=sharing";$B$1&"!C2:C100")

Column with Sergei's ratings (cell E4):

=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1AlMWqIUrVFIzgT3C9N-g2tPGQ5EtHOZlk6I6IRLxQtY/edit?usp=sharing";$B$1&"!C2:C100")

We insert these formulas into the first rows of the columns with ratings. It is important to open access for connecting external tables.

Setting up access

Setting up access

Developer Files – Automatically import Jira links and descriptions

Synchronizing task descriptions

Synchronizing task descriptions

Jira issue columns + Description (cell A4):

=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1uMWqq6-OQmnrJkAko6_F3y87bIy0ZwjBuEYm9vCuxP4/edit?usp=sharing";$B$1&"!A2:B100")

This formula imports the tracker links and task title from the range A2:B100 on the Backlog sheet from the Summary file. Note that the sheet name is listed in cell B1.

Time Estimation

So, everything is ready to try the tool in action.

Let's add links to the tracker, as well as names and descriptions of tasks to the main “Summary” file. This description is automatically imported into the developers file for time estimation.

Description of tasks

Description of tasks

Let's write to our developers in the chat and ask them to evaluate 14 new tasks:

Nikita, Alina, Sergey, hello!
Please estimate the tasks on the Backlog sheet today.

  • You must enter an estimate in hours.

  • Round to the nearest whole value.

  • If there are difficulties, then you don’t have to give a rating.

File links:

Nikita

Alina

Sergey

It wouldn’t hurt to talk to the team for the first time about why this is being done, talk about the anchoring effect, and show what is expected of them.

The developer will independently open a file specially prepared for him, go to the Jira link, get acquainted with the statement prepared by the system analyst, and set the clock for each task.

We will assume that the information described in the statement is sufficient for a correct estimate of time. We will leave the question about the completeness of the input data outside the scope of this article.

File with completed grades

File with completed grades

After all developers give ratings, information will be automatically collected with which you can further work.

Summary table with backlog estimates

Summary table with backlog estimates

1 – Task estimates (hours).

2 — Maximum value (hours).

3 — Median value (hours).

4 – Average value (hours).

5 – Total amounts for maximum, median and average estimates (in hours).

As you can see, the assessments of Nikita, Alina and Sergei are almost the same. From this we can conclude that the guys have a consensus about the complexity of the tasks. Moreover, we achieved our goal, avoiding the binding effect and large time costs.

Next, you can break down this scope of epic work into sprints to determine the implementation period, which was described in detail in another article.

It's a different matter if the estimates differ significantly. However, even in this case, we will still save time, since we can discuss point-by-point only those problems where there is a large spread in estimates.

Analyzing the ratings

Analyzing the ratings

For example, here you as a manager must:

  1. Ask Alina why she believes that it takes so much time to implement the createCart and updatedClient methods, and also what risks she sees.

  2. Ask Sergey why he couldn’t evaluate the deleteCart method, as well as what points he doesn’t understand.

If necessary, you can organize a meeting to discuss specifically these issues in an expanded format.

Retrospective

It is useful to return to the estimate table after completion of work to analyze the difference between planned and actual time. Such actions will be useful both for you, as a manager, and for developers to improve their labor intensity assessment skills.

Retrospective

Retrospective

1 – The actual time matches the estimated time.

2 – Actual time is greater than estimated time (underestimation).

3 – Actual time is less than time estimate (overestimation).

Further use

The preparatory steps with which we set up automatic data import make it quite easy to reuse this approach for estimating new work.

The simplest option:

1 – Update the links and task descriptions in the main “Summary” file.

2 – Delete old developer ratings in their files.

You can now evaluate the same files again.

In our practice, we prefer a slightly different option, in which we duplicate sheets with a list of tasks so that the data is saved. This way we save historical data on past assessments:

File relationships

File relationships

Bottom line

We looked at a task assessment tool that can help avoid the anchoring effect almost as well as planning poker. However, it is worth noting that what is described is not a replacement. The purpose of the article is to share another tool that can expand the arsenal of a successful leader and help in solving similar activities.

Like any approach, this tool has its pros, cons, capabilities and limitations of use. Nevertheless, in our practice it has proven itself quite well. I would be glad if the tool turns out to be useful in your practice.

I welcome your comments with ideas, comments and thoughts.


Link to folder with files for assessment https://drive.google.com/drive/folders/1jx7tunEft2ax90UcJzbTgI3rRC7bkEQM?usp=sharing

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *