There are some Agile Teams I have witnessed where a “Sprint Velocity” metric is used as an “input” to the Agile process. This is particularly manifest when third-party development teams are involved, where the Velocity concept is used as some sort of “budget” against which a customer can “purchase” their Product Backlog items. This might give a clean “pound-per-point” contract position but does go against the Agile manifesto (“customer collaboration over contract negotiation…..”).
Other teams I’ve observed follow a similar concept and use Velocity as some sort of capacity limit – filling the Sprint Backlog with Stories (and Story Points) up to – but not over – the Velocity figure. Even more surprising I’ve also witnessed teams (few, it must be said) that estimate the stories as part of Sprint Planning and – surprise surprise – the total number of Story Points for the Sprint matches the team Velocity (there is a reason why tools like Jira do not allow estimates to be applied after a sprint has started).
How is velocity expected to increase in these kind of environments? At best it will remain constant, but normally it will embark on a downwards trend.
For me, Velocity is an output from the Agile process and not an input (to). Velocity is not something that you can control or indeed something to be used as a control. It simply gives a current reflection on the performance of the team. It will fluctuate and change over time but it is key that it follows a generally upwards trend.
Treat velocity with respect and use it wisely.
One of the key reasons I like Agile and Scrum is the fact-based approach to forward planning. The team who actually deliver the work, estimate the work. The same team then deliver that work to the best of their ability – delivering a (hopefully) increasing velocity figure. That velocity figure can then help with visualizing how long the Product Backlog, in whole or in part, can be delivered based on current velocity. This is fact-based Release Planning and is more accurate than any other guesswork.
Key takeaways: Velocity is an output, not an input. Velocity should exist in an environment which encourages it to increase. Velocity is a fact that can be applied to more accurate forward planning.