What are the benefits and challenges of using story points for sprint estimation?

Story Points are relative numbers derived upon comparison with a baseline task. It considers effort required together with complexity of the task.

I like to frame one of the main benefits of Story Points less around estimations and more around thought provocation. With story pointing, you are engaging Development to think about what are some risks and possible dependencies/blockers with a certain task. Then, it's less about the pressures of committing to a time estimation and more about a point value correlating with you as a developer's confidence level to see that task to a Done state.

Story points can be helpful, but here are three key things to watch out for: 1. Product & leadership should avoid taking story point estimates and directly converting into a deadline. Story points are estimates, and often not high confidence. 2. Story points are often used in a modified Fibonacci sequence to indicate the higher variance with larger efforts. When a team comes up with a story point estimate, ask them for a confidence level from 1 to 10. This helps set expectations between Engineering & PM. 3. Watch out for any method that tries to compare story points across teams. This unit of measurement is designed to not be compared, as teams have different units of measure.

Yes! we use every opportunity to collaborate and communicate in a team. Story pointing is a good one, especially when developers do not agree on the estimate a colleague has given. A healthy conversation results. Learning and growth take place, as they explain themselves.

To build on what @Claude said, my teams often start with one story point being the cost to write, validate, and deploy a one-line configuration change to production. This can be a helpful starting point for what a "1" represents.

One of the challenge is to have the entire team to align on what represents a story point. It is crucial that all stakeholders share the same definition of a story point, over the sprints. I'd recommend to spend time at the beginning to have a good discussion and explanation of it, so point values keep consistency throughout the iterations.

I've always advocated for Story Points to vary team to team. But Story Points shouldn't be a company wide single measurement. A "3" for one development team could mean something different for another. When facing challenges with using Story Points, the emphasis I put on it for teams is that this is a measurement of complexity, risk and ultimately your personal confidence level to complete the task at hand. As teams mature, the evolution of what constitutes a "3" may reach a point where the gap between teams will narrow if those teams are working on similar bodies of work. The goal is to build confidence, mitigate risk and have clearly written stories. Not hold development accountable for time measurement through Story Points.

One of the best reasons to have story point estimates is to notice when there is a spike (or a drop) in velocity for a sprint, and then to discuss the reasons. With a drop, the goal is not to blame, but understand what slows the team down. With a spike in velocity, the goal is to understand if the team did something worth replicating vs. whether they are simply experiencing "bounce" (when a team just misses sprint end dates, the velocity will alternate between higher + lower numbers).

At some point, a team that has done story point estimates will eventually realize nearly all stories are now nearly the same size. At that point, the team could consider whether story points are still valuable. However, I would strongly caution teams from bothering at all with priority. All that matters is relative stack ranking on the backlog. The team likely doesn't do anything that is "low priority", and calling an item P1 (or P0) isn't meaningful if it's not at the top of the backlog (or in the next sprint).