We use story points in our SaaS product startup. In a larger company that I consult at, whose main business is not a software/technology product (but IT/software is a core enabler for their business), we tried story points, but eventually settled with hour-based estimates. I think the difference was in team sizes, nature of business and delivery timelines.
In the startup, we had a small team where everyone was aware of the agile processes, and the delivery timelines were based on the estimates.
In the larger org, agile processes and story points meant a change in the culture from the traditional waterfall-oriented process they followed. And larger team sizes meant it took a longer time to change the culture and thinking. Also, due to the nature of the business, the delivery timelines are stricter, and sometimes already decided before IT was involved. Projects also often involve multiple non-IT teams (sales, marketing, customer service, etc.), and it is easier to communicate in hour-based estimates to them. We still do agile development as much as possible, but settled on hour-based estimates.
We don't call them story points, but we have 3 classifications:
1 point: can be done within a week
2 points: 1 week to 2 weeks
3 points: needs more research and breakdown, possibly an epic
1 and 2 tend to be picked up and worked on directly, for 3 someone picks it out and the goal is to create more tickets based on it and not do the solution directly.
We use estimation in days, for longer running project wherever have a collection of user stories we are tackling we tend to use the average cycle time for the team (how long it takes from starting the issue until it is done) multiplied by the amount of issues we are tackling.
Story point estimation seems like a really popular approach to sizing work and getting to alignment on complexity. Curious to hear from teams that have had either a positive or negative experience with estimation.
In the startup, we had a small team where everyone was aware of the agile processes, and the delivery timelines were based on the estimates.
In the larger org, agile processes and story points meant a change in the culture from the traditional waterfall-oriented process they followed. And larger team sizes meant it took a longer time to change the culture and thinking. Also, due to the nature of the business, the delivery timelines are stricter, and sometimes already decided before IT was involved. Projects also often involve multiple non-IT teams (sales, marketing, customer service, etc.), and it is easier to communicate in hour-based estimates to them. We still do agile development as much as possible, but settled on hour-based estimates.