The value of story points is that it acknowledges that not all stories are equally time-consuming. Importantly, story points also provide a process for identifying stories that should be further decomposed.
In my experience, story points allow forecasting that's as good as any forecasting method I've ever used. And I've used pretty much every schedule forecasting method over my long career.
The author touches on many of the reasons why story points don't work. And pretty much every reason he gives is something that you are not supposed to do.
The key to getting them to work is trust, and a commitment to never use story points as metrics to measure the performance of developers. Any attempt to do so will result in gaming of the system. The tradeoff that stories provide is lack of precision in exchange for not having to spend 50% of your development cycle up front doing detailed analysis required to provide detailed estimates (which never worked anyway).
Things you must also never do:
- compare calibrated burndown factors between teams.
- Ask why the calibration factor isn't N. THe calibration factor is.
- Have stories with more than N story points (where N is 3 or 5). Decompose them.
- Introduce the least bit of stress.
- Use burndown rates to generate commitments, instead of forecasts.
- Use forecast results to justify asking developers to work overtime.
The last point, I think, is particularly interesting. The manager who was my first scrum master made the following commitment to us: you will never work overtime again. And voluntarily working overtime will be consider a bad thing, not a good thing, since it impairs predictability of the team's productivity. "I know you don't believe me", he said. But he was right. We never worked overtime again.
In my experience, story points allow forecasting that's as good as any forecasting method I've ever used. And I've used pretty much every schedule forecasting method over my long career.
The author touches on many of the reasons why story points don't work. And pretty much every reason he gives is something that you are not supposed to do.
The key to getting them to work is trust, and a commitment to never use story points as metrics to measure the performance of developers. Any attempt to do so will result in gaming of the system. The tradeoff that stories provide is lack of precision in exchange for not having to spend 50% of your development cycle up front doing detailed analysis required to provide detailed estimates (which never worked anyway).
Things you must also never do:
- compare calibrated burndown factors between teams.
- Ask why the calibration factor isn't N. THe calibration factor is.
- Have stories with more than N story points (where N is 3 or 5). Decompose them.
- Introduce the least bit of stress.
- Use burndown rates to generate commitments, instead of forecasts.
- Use forecast results to justify asking developers to work overtime.
The last point, I think, is particularly interesting. The manager who was my first scrum master made the following commitment to us: you will never work overtime again. And voluntarily working overtime will be consider a bad thing, not a good thing, since it impairs predictability of the team's productivity. "I know you don't believe me", he said. But he was right. We never worked overtime again.