Measuring velocity is not enough to determine team productivity

From my perspective, velocity should be used for planning purposes only i.e. how many user stories I can plan into a Release or Sprint based on my teams previous velocity (using story points of course).

Knowing your teams velocity is an important part of Scrum. Knowing your velocity is also central to lean thinking in that it defines the capacity for how much work your team can manage at any given point in time. It's important to note that velocity only remains static if the teams conditions remain the same. For example, if the team composition changes, velocity will change. If changes are made to the process (e.g. start pair programming or start writing unit tests), then you can expect velocity to change as well.

I think that Paul Hodgetts, Agile Coach and Certified Scrum Master, said it best when defining the purpose of measuring velocity:

“Velocity is more of a quantity of work completed metric. Useful and important, but not the sole measure of success. I think you would want a set of metrics that together help us understand our current capabilities to deliver as well as if those capabilities are changing from one point in time to another. I don't believe there is one magic "agility number" to measure [productivity].”

Another important aspect of velocity is that it's a measure of how much work is fully completed at the end of the Sprint i.e. represented by how many completed stories there are at the end of the iteration.

Relieving pressure

Moreover, why I am such a big fan of velocity is because I believe that once a teams velocity has been established, it takes a lot of unnecessary tension out of the development process. In my 20 year software development career, I have rarely had a situation where the business fully trusted the development team. It always seems to boil down to the development team not working hard enough, leading to many hours of overtime and ultimately burnout.

Velocity on the other hand is the neutralizer. Once this number is established, the business gets used to understanding how much work can be shoved into the development pipeline and have a good chance of being delivered on time Sprint after Sprint.

Why it can't be used to measure productivity

I think it's worthwhile explaining why I think velocity is not a great indicator of productivity.

Productivity in my book is how efficient my team is, while velocity can tell you how much you're getting done; it's not going to tell you if you should be getting this done faster or not. One would have to look to industry standards to try to measure productivity like function points.

Consider this...

Your team could have reached it's sustainable throughput, continuously delivering the same amount of software, and still be counter-productive. Why? Because you later find out that what you just delivered didn't result in any value! At the end of the day, it’s the customers and stakeholders that measure the success of the project. Velocity isn’t the end game, the most important thing is that you’re delivering features that the customers want and with quality that’s expected by them.

Conclusion

In summary, what's important is that the team is delivering value in a sustainable fashion (value as determined by the customer). So in order to enhance productivity, there are many things one can do:

• You have to get the requirements down pat. The best way to do this is to work with the customer to define the user stories and get their intent up-front.
• Ensure you are capturing the acceptance test criteria from the customer up-front. This helps solve the greatest risk of all – getting the wrong product.
• Define your definition of "done" up-front so that there's no argument at the end.
• Ensure you build quality in right from the start.

If you do this well, your teams will become highly efficient and the need to measure productivity in the first place disappears!

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com