Throughout my career, I’ve harboured some heretical “unagile” and unsanctimonious ideas. But none seemingly, quite as heretical as this one. A lot of people read that and think what I meant to say is…

Roberto Umbelino

Figma

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

The use of story points in agile estimation doesn't make sense because they can't be added up. Using t-shirt sizes instead of numbers can be a more accurate and consistent approach.

Why Story Points don’t make sense

I am yet to work in a business where story points and t-shirt sizes (if they were even used) were not then converted to time, because… the business always needs to know “how long” something will take.
So we spend each planning session relatedly wasting a team’s time arguing over the definition of each size, then arguing over the size of each item, only to turn around and turn it into time. 🤷‍♂️ Skip the BS and just work with time.

We use fibonacci story point system and it seems to be far more accurate thru the duration of the sprint.
1 point: can complete multiple a day
2 points: one dev one day
3 : one dev a couple days
5: one dev one week
8: one dev one sprint

I use story points since forever, and quite successfuly, but not blindly. There are some caveats.
The thing with story points is that they can describe more accurately situations taking expertise into account and can be used to median the technical/operational capacity of individuals and teams.
Later, that measure can be used to estimate entire projects with great accuracy, specially if you have standardized tables of similar complexity features to reference to.
But, I can’t emphasize enough “technical capacity” because it’s absolutely true that story points cannot be converted directly to describe time complexity.
That conversion must be made by the technical leaders of the team, by knowing (and in close collaboration with) their teams. And it is crucial to do it to know your teams!! Different seniority levels behave and execute at different ratios and with varying autonomy, which make immediately unfair to measure them in hours.
If you measure performance, you can’t decouple expertise out of the equation.
Since product-sided stakeholders like PMs don’t have that technical background, they tend to understand better time complexity. Hence the eternal dispute.
My answer as Technical Leaders is: As with everything in this field, there will never be a way to measure projects that work for everyone and every project. Story Points excel at large projects (Quarter sized or more) with relatively stable, in-house-predominant teams.
For other smaller, quick, or freelancer driven projects hours might be a better solution: you don’t to measure the evolution over time of your teams, you only want to get your deliverables as fast and precisely as possible to cut investing in freelancers asap.
Finally, if the situation requires, I like to be the bridge and do the time complexity translations at deliverable/feature level and let the stakeholders do the math. Keeping everyone happy with their numbers.