Story points are a tool for communication and planning, not a measure of success. Yet, because of how easy it is to track story points, it’s easy to fall into the trap of using them in the wrong way. Scrum teams can start thinking that their value is in their velocity and this misguided train of thought can lead to decisions that, in fact, dampen success.
Rather than being defined by story points, success is defined by the organisational vision. For most companies this will be measured by return on investment and how much value is delivered to the customer. The more value we deliver, the greater customer satisfaction.
An important distinction to make is that more value doesn’t mean more features. In 2002 the Standish Group found that only 20% of features were used always or sometimes, and 45% of features were never used. If an increase in velocity just outputs more features that aren’t likely to be used, or worse, more bugs, then developers might be outputting a lot without adding to customer value.
What we want to do is deliver more valuable pieces, not more individual pieces or even bigger pieces. How do we make pieces more valuable? We need to focus on quality. That means stable software that provides an intuitive user experience. We also want to focus on adding features that solve users’ true problems. How well we solve those problems, and how important the solution is to the user will determine the value of the changes to the software, regardless of what story point value has been given to the piece of work.
That doesn’t mean that story points and team velocity aren’t useful. Tracking velocity can help a team and the organisation to understand their capacity and give the business an indication of whether the effort to implement a feature will exceed the value it delivers.
When using any numerical metric it’s important to understand what it measures. Velocity isn’t a magic bullet for measuring performance. Numbers alone never tell the whole story and can only guide us if we use them in the correct context.