Silent Grouping for Estimation. Does It Work?

Silent Grouping is not the most common estimation approach, but it has started to gain popularity recently. If you haven't used it yet or haven't heard about it before, don't worry too much, I will try to explain.

The essence of this technique is that all team members try to estimate the tasks independently, without a prior conversation. Silently.
Then, they reveal their votes and discuss only the items for which they don't have a consensus.

– If everybody agrees that this task takes 3 Story Points, why should we talk about it?

(c) Typical Silent Grouping advocate

If you wonder when you should use Silent Grouping for estimation, I will save you some time.

You should avoid Silent Grouping as much as possible.

If it was enough to convince you, please check out other notes about estimation and subscribe to new posts. If you want some argument, keep reading :-)

Which metrics do you optimize?

Let's try to answer it together.

So, you want to change the way you run your estimation sessions. Usually, it means that you want to improve something. But what exactly?

Silent Grouping claims to save time, so I suppose this is your metric. Some people claim that Silent Grouping allows reducing time on estimation in more than 150 times! Must be a huge win.

What is about other metrics? I mean, if all you only care about is time, it would be easier to stop estimating at all, it would save you much more. I suppose there are some reasons you still want to keep estimating (or check Who Needs Estimation if you aren't sure).

The most common reasons are:

1. You want to reveal unknown unknowns – hidden risks which the team hadn't identified yet
2. You want to find the most suitable solution
3. You want to be as precise as possible in your estimation
4. You want to bring the team together and initiate insightful discussions

Let's think about how these goals may be affected by using Silent Grouping.

Silence will fall

The fundamental ingredient of Silent Grouping is silence. People don't discuss tasks before estimating them. We can model this situation.

Imagine a team of three people: Jane, Lucas and Bob. You may be already familiar with them by the note What Real Madrid can teach us about leadership, but don't worry if you aren't. All you need to know is that they're great engineers and want only the best for their company.

Let's put them into a room and ask to estimate one story:

As a user, I should be able to add comments to the news articles.

They also have a description of this story from a Product Owner:

1. Only the users with a paid membership can comment
2. Comments are permanent, and users cannot remove them

The wireframes are attached.

The team is all set and ready for the first phase of Silent Grouping – Individual Estimation.

There is how it goes:

1. Jane thinks that the main work would be done on the server-side. They would have to optimize performance for the high load, as the widget of comments should present on all news pages.
   She remembers that similar tasks were estimated as 5 story points in the past, so she decides to vote for it.
2. Bob thinks that the backend part should be trivial because all they need to do is to write and read from the database. But he knows that the client-side part would be tricky. The existing code there is pretty bad, and they don't have any tests around it.
   Last time they touched this part, they estimated it as 5 story points, so this one should be similar.
3. Lucas thinks that both backend and frontend shouldn't cause significant problems, but he knows that their designers can suddenly come up with a new set of wireframes if they changed their minds.
   While he thinks that this task looks similar than the ones they previously estimated as 3, he picks 5 to budget communication overhead they would probably have.

When the team finishes with individual estimation, they can move to the second part – Group Placement:

And they almost finished. Now it's time to put 5 story points into the task tracker and praise themselves on how much time they've saved.

Downsides

The main drawback of this approach should be visible now – the team doesn't share the same understanding of upcoming work and potential pitfalls they may encounter.

If Jane picks this task, she will be unpleasantly surprised that the actual effort is three times higher than they expected.

One-Person Silent Grouping

Another popular technique that leads to the lack of common understanding is One-Person Silent Grouping.

Usually, people use it when they try to estimate tasks before the deadline:

Together with authority bias and fear or urgency, it gives worse results than a classic Silent Grouping.

Also, it doesn't contribute to the typical learning cycle, so the team doesn't improve their estimation skills for this type of tasks:

But what to do if I have a deadline?

Here I have two suggestions:

1. Talk! Describe your reasoning and be ready to answer questions
2. Try to free your team from authority bias.
   The easiest way to achieve it is to make sure that the people with more authority (managers, more experienced engineers) talk last and they don't propose an initial suggestion

Summary

In the end, it boils town to 4 points:

1. Silent Grouping is a useful technique, but not for estimation. Use it for sprint retrospective or bug triage – those are different meetings
2. Always explain why you decided to pick the value X rather than Y, especially when you estimate alone
3. Think about the metrics you try to optimise before investing in a new approach. Make sure nothing major is damaged
4. If you only care about time, maybe it's worth to stop estimating at all?

The cover photo by Maria Krisanova on Unsplash