The only working way to estimate story points

panaetov — Fri, 07 Feb 2025 18:14:55 +0000

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.

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.
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.
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.

What is DDTM (Data Driven Team Management)?

panaetov — Thu, 06 Feb 2025 17:47:24 +0000

All good managers do it...

Being a good team manager is tough...

Often uncertainty is your biggest enemy, and one of your most important goals is to provide predictability of team results in terms of quality and timings.

So, how to achieve predictability?

This is not a simple question, because software development is not only about algorithms, system analysis and data centers. It ismainly about people and those who believe that their work is kind of art and self-realization.

Not very seasoned managers may think that the only way to go is to rely on a subjective assessment of the team's performance.

This may work in some situations, but it will be useful to combine subjective assessment with more rigorous metrics-based analysis using a Data-Driven Team Management approach. What is it?

Your team generates a lot of digital breadcrumbs and artifacts when it works. These may be issues in Jira, commits in Gitlab, messages in a corporate messenger. Using this data, you can analyze your team, building metrics. Of course, such analysis cannot completely replace the subjective assessment, but it can be an important source of interesting insights.

What tools can you use for building such metrics?

Ad-hoc tools.
Many people prefer to create their own tools. For example, you may download data from Jira and analyze it using Excel. The advantage of this approach is simplicity. The main disadvantage is that such tools do not have the proper level of automation and it is difficult to use them on a regular, daily basis.
Built-in analysis tools in Jira, Github, etc.
The advantage is seamlessness. The disadvantage is that such tools can be unavailable to you or not flexible enough, so you cannot analyze specific cases specific of your team.
Special DDTM tools.
We can mention, for example, open-sourced Captain-Bridge, with realy good documentation and growing community. It allows you to create custom metrics using syntax of mongo or python and data of Jira, Github, Gitlab, Telegram and Discord.

DEV Community: panaetov

The only working way to estimate story points

What is DDTM (Data Driven Team Management)?