Does your Team has a Velocity Problem?

In our coaching practice, we often see a big disconnect between agile teams and senior leadership around the topic of velocity. Velocity was designed as a forecasting tool for teams to create a sense of predictability for product owners and stakeholders. After a few months into a project, teams usually get fairly good at this, thanks to empricism and the Scrum Masters maturing the teams in the application of the Scrum process. 

On the other hand, senior leaders often read velocity as a productivity metric and translate numbers into charts. Those charts end up in Powerpoint decks and find a way into board meetings and so forth. Using velocity points for measuring productivity is not entirely wrong, but just doesn't tell the full story. For example, does a team become less productive if 1-2 developers leave the team? Or, why does the productivity of a team not increase linear by adding 1-2 developers? This model falls apart fairly fast.

The other issue with velocity is, that it actually doesn't only include speed but also direction. Using agile development to create complex products, pulling in one and only direction isn't desirable either. Is a team less productive by possibly taking a painful detour to accomplish a better end result even if it requires a dip in velocity? What behavior are we rewarding? 

Last but not least, we could also argue that we create a wonderful high performing team that increases velocity sprint by sprint, but they are being given low-value items to work on. In this case, an agile team might might be extremely efficient building a low value product. Does not sound appealing to me either.

I am suggesting something like outcome and let teams derive projections for future sprints from it and have agile leaders use the outcome to measure impact and productivity. Outcomes should be linked to the increment and we have tons of metrics the various parties can use to measure value on one side while forecasting with some different metric. 

Jochen Krebs