Thoughts on Story Points as a Software Development Metric

Aka the byproduct of Planning Poker. This metric has by far the most promise of the group. If done well, it can leverage a group’s unbiased judgement to provide a useful starting point for measurement. GitClear allows customers to collect their Story Points as a part of the puzzle to understanding how much is getting done.

The main weakness of Story Points as a metric to measure developer productivity is that it often fails to credit the day-to-day work outside the scope of a neatly-scheduled sprint.

If you happen to work on a team where 100% of development takes place in a predictable, planned way, then Story Points can be a viable solution for developer measurement. More likely, you’re working in an ecosystem where such rigidity isn’t viable. The real world is a messy place, and it lays waste to great plans and good intentions.

The reason that Story Points makes this list is that an incomplete solution can be worse than no solution. If 80% of your development efforts happen via tasks that had Story Points assigned, you’re still losing 20% of your signal. It easily beats a metric like Lines of Code with its 80%+ noise, but it misses a swath of important work the team is doing. On a busy repo like Tensorflow, work done as part of an issue is only about 50% of all commits made.

For being deceivingly good, Story Points earns the fifth spot on the list.