The only working way to estimate story points

All good managers do it...

Estimating story points can be challenging... Why is that?

The main reason is that not many people truly understand what story points are. They seem to be shrouded in mystery and magic. A lack of understanding leads to a lack of trust and a cargo cult mentality. And eventually, teams may stop using story points and revert to using estimation in terms of days.

I've tried many approaches to estimation: T-shirt sizing, scrum poker, and more. Believe me, they all have their flaws.

T-shirts aren't flexible. You categorize issues as small, medium, and large, and that gradation is quite coarse. Also, if you use T-shirt sizing for estimation, it's not clear how to measure velocity: how can you compare two medium-sized issues to a large-sized one, for instance?

Scrum-poker is a kind of marketing buzzword. It is too subjective and, in most cases, unrealistic due to the Theory of Constraints.

The only effective approach to estimation is the Estimation Through Decomposition (ETD) method. Let's talk about it.

1. Decomposition, not estimation. IT engineers are not good estimators, but they are great decomposers. It's pointless to ask them for a direct estimation, as estimation is about stress and self-confidence, which are subjective. On the other hand, decomposition is a clear and safe process that engineers do all the time. Decomposition is not stressful, and the resulting list of sub-issues is objective and can be discussed objectively by the team.
2. Standardize sub-issue sizes. For coherent decomposition, you need to establish a convention for the standard size of subtasks. This is the only direct estimate you will make. In our team, we have agreed that a standard subtask is an activity that can be completed in about half a day.
3. Storypoints = number of standard-sized subtasks. After dividing the task into standard-sized subtasks, you have an estimate that is simply the number of subtasks.

What next? How to use estimations?
Estimating allows you to calculate some important metrics, such as team velocity or the percentage of completed tasks planned for the sprint.
To create such metrics, you can use the great open-source tool Captain-Bridge, which has excellent documentation and a growing community. It allows you to create custom metrics using the syntax of MongoDB or Python, using data from Jira, GitHub, GitLab, Telegram, and Discord.