Comment by madeofpalk
2 years ago
“Story points” help you predict your work in the future. Knowing what and when you deliver can be valuable!
Say you’re developing software for the next Super Bowl broadcast - it’s useful to know whether you’ll deliver what you said you would. If it’s looking like you can’t, you can start to make educated decisions about what work to cut and get a better idea of what you actually will deliver.
The criticism of the GP is that teams at his company would estimate story points differently depending on how much stress they wanted to take on and not based on the complexity of the work. This had the impact of the low stress teams not taking on ambitious work. Whereas teams that would take on ambitious work and attaching points to that work were working at unsustainable levels to meet targets.
In your Super Bowl example, you'd either get a team that would focus on doing the scrum activities but never deliver anything useful regardless of how many points it would take, or you'd get a burnt out team that's on the verge of flaming out. In either case "Story points" provide you with no predictive capacity even though predicting would provide value.
The predicting value is only per-team. If your team does 10 points per sprint, it won't deliver 20. If it does 100, it will.
But it's an important tenet of scrum that velocity is only meaningful in a single team[0], the root management failure in OP's case is comparing different teams.
[0] and teams cheat themselves too. I recall one advice early in my career that a velocity increase with no underlying process change was likely to mean.. that the team started to overestimate complexity, and one should understand what went wrong.
If your team is doing mostly similar work and the team has the same composition for a long period, points can have some meaning.
When a team shifts projects, and changes members, there are too many variables and not enough data points, so points become useless.
Since most teams change both of those thing fairly frequently, in the close to 20 years I’ve been doing this, points are generally not helpful.
They don't help you do that, even though poor non-technical managers might think they do. That's why good software projects don't use them. I don't see any story ticket velocity points used in Linux kernel development.
You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.
I didn't say I would "deliver" anything. It's done when it's done. You can't predict the outcome of a software project. Many of them fail and micromanagement makes them more likely to fail.
> You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.
so if you automate trivial predictable work (for example by making a CRUD app generator), you're moving to non-trivial software territory with costs unknown (as you said, you can't estimate), potentially very high
Or you don't and end up making a non-functional website for the public sector for $100M. Software projects fail often, and not for the lack of trying, there is not yet any evidence that you can micromanage them into succeeding.