Every time I heard somebody about increasing velocity a red light switches on my head.
Most of agile projects tend to have a velocity. The velocity tells us how much the team can achieve within an iteration. Velocity gives us predictability and the team should focus on keeping it stable all the time.
For example, in a typical scrum project the team estimates user stories based in complexity. A common pattern is to use Fibonacci numbers for this. When the sprint finishes, usually a 2 week iteration, we can sum up all the points of the completed stories and get our current velocity.
This velocity is expected to fluctuate at the beginning, but to get stable later on. Through the project the team will get better at estimation, will learn how to collaborate well and ultimately should always have the same velocity. The team should be able to do the same work (velocity) at the same time (sprint). Which is great because it will give confidence to the stakeholders, they will know which features are going to get in production the next sprint!
I’ve seen many places trying to increase the velocity of a team just to get the project finished earlier. Or companies where they would compare velocities between two teams. I’ve also heard project managers trying to add extra stories to the sprint just in case the team could complete them this time and therefore increase the velocity. All of this behaviors are a misunderstanding of what velocity is meant to be for.
I think the source of the issue is that velocity is based in numbers and it is very tempting for managers to try to increase them. It really looks good in a power point when you see those numbers go up! I have seen team using different measures for estimation, like T-Shirt sizes (XS, S, M, L, XL). Maybe that could be a solution, but I haven’t tried that yet, so I can’t tell. When it comes to estimation I like the idea behind lunar cards, but that’s going down the path of #NoEstimates and maybe is a topic for another day..