Scrum teams often use story points to help them estimate the amount of work they can do in a sprint. Are story points a good way to assess a team's productivity?
What are story points?
In Scrum, a team will commit to completing a number of stories (i.e. tasks) during a set period of time called a sprint. In order to predict how many stories they can commit to, they track how many they completed in previous sprints, along with the relative complexity of each. This relative complexity is called story points - an indication of how complex the team thinks a story will be. A 2-point story is considered twice as complex as a 1-point story and so on. Read more about story points here.
What are story points good for?
As a team records the stories it completes in its sprints, it is able to determine its velocity. This velocity is the total number of story points the team completed in its last sprint. The team's velocity is useful for a number of reasons.
The velocity can be used to decide how much to commit to in the next sprint. During sprint planning, the team shouldn't pull in more stories than what adds up to their current velocity (or if they are pulling in more, they should be comfortable with why they are doing so).
For the team's product owner, the velocity can be used to project an estimated timeline for possible future deliverables. At the very least, they can answer questions like "how soon can we do X?" with answers like "certainly not until at least month Y or quarter Z".
Trends in velocity can also indicate problems. If the velocity fluctuates then the team might be in a cycle of over-committing then dialling back to compensate. If the velocity doesn't increase after new team members join then there might be an information flow issue on the team.
Are story points a good gauge of team productivity?
Story points are a tool that help a team do their work consistently. Since they are subjective and relative, the velocities of two teams producing the same output might differ. It's possible that say a 2-point story on one team means a different thing on another team. That's okay. There doesn't need to be a standard for story point meaning because they are merely a mechanism for a team to help it organize itself.
Story points help teams measure the "means" by which they do their work. They don't measure the "ends". It's perfectly possible for a team to do a whole ton of work (resulting in a stellar velocity) that doesn't deliver much actual business value.
So in the end story points don't give a good indication of productivity. At best, just busyness. They are technically a capacity metric, not a productivity one.
How should you gauge a Scrum team's productivity?
When measuring a Scrum team's productivity it's better to consider what outcomes you wish to see the team achieve. You can figure this out by asking: which features does the team intend to ship during the next time period?
In addition to outward-facing product goals, the team might have some internal items it wishes to implement. These usually fall under "tech-debt repayment", such as better test coverage, re-architecting certain code to support future extensibility or the creation of a staging-based testing process. The team could add such items to their objectives list then define KPIs based on them.
It's important to involve the team in this process. They should play a part in setting their own goals. If they're not aware of how to choose goals according to larger company objectives then that naturally leads into a discussion of what the larger objectives are. Such a conversation is great for alignment and an understanding how to contribute to the greater good.
