Is it a good idea to link a team's sprint velocity to bonuses or salary increases?
For example, if one increases the average sprint velocity by 10 percent at the end of a year?
Or are there other metrics that could be more useful?
Is it a good idea to link a team's sprint velocity to bonuses or salary increases?
Velocity is a tool teams use to forecast things and plan future work based on how the team has done in the past, in similar conditions. It is not a performance target. It is not a management metric.
If you tie bonuses and salary increases to velocity, two things will happen:
There are better approaches to measure developer and team productivity, and make pay raises or bonuses more meaningful when attached to those, but those have their challenges too, as it's hard to measure knowledge work from outside. There is a lot of information out there, and some work better than others depending on the context. Maybe you could start reading from these two links:
Just remember that if it's easy to measure or really handy, it doesn't necessarily mean it's useful or meaningful.
There have been good answers already, but it is also worth mentioning that this approach would discourage any activity that wasn't measured by velocity.
A team might not include in their velocity things like training, knowledge sharing, helping other teams, answering questions from stakeholders, etc.
Why would you link pay to any measurable aspect of development work?
It seems to me that this starts from the assumption that some kind of incentive will deliver benefits to the firm in excess of the additional wages paid.
Nothing is likely to be further from the truth.
There's absolutely nothing about the productivity of development work that is measurable by any mechanical means.
And there is no evidence that paying developers by any measure of productivity, improves either the speed or quality of results. Ever. It's been tried so many times over so many decades.
A fundamental problem (but by no means the only one) is that developers are primarily engaged in work that is internal to their own minds, and the relationship between the occasion of that internal work and the effectiveness of any output is not amenable to any method of external measurement.
Effective developers are often self-motivated in the first place - motivated by a desire for some kind of craft proficiency. Most people with decent jobs have this motivation - it's not unique to developers.
How the criteria of that proficiency are conceived, and whether proficiency is attained, is a complicated expert judgment, and there may not always be agreement between any two experts, but there is no doubt that the judgments are constantly being made by the developer in order to direct their attention and activity in a way that promotes their effectiveness.
Mechanical measures of productivity never succeed in replicating the subtlety or constant adaptation of these judgments.
So what happens when you apply such measures and incentives, is you get a bifurcation into two types of developer.
One type adapts its behaviour in response to the incentive (including adapting towards gaming the measures), and ceases to be guided by any internal judgment (and perhaps even ceases to perform it). A considerable amount of brainpower that they should be applying to development, and usually would be, is then reallocated to this gaming.
The other type of developer maintains their internal judgment, but is either punished by the measures for actually doing their job effectively, or is at least constantly threatened by being punished by them. This distracts and demoralises to the point that either the developer leaves, or at least there is overwhelming resentment induced (and a major withdrawal of engagement and effort, in a way that cannot be measured).
In both cases, the business attempts to substitute their own crude measure of productivity for the subtle and dynamic judgments of the developers themselves, and in doing so either undermine one of the main skilled activities that developers are actually expected to perform, or provoke so much conflict over those judgements as to undermine motivation and divert attention from development.
I just wonder whether any reasonable argument will alter the course of those who are determined to measure the unmeasurable and find metrics where none exist.
Velocity is not a measure of productivity. It's a proxy metric for team capacity used for forecasting and capacity planning. More generally, it's a useful tool for estimating whether a given amount of planned work on the Sprint Backlog can be reasonably expected to be completed within a single Sprint.
CodeGnome's Scrum Tautology℠ says:
Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.
Trying to use velocity to measure productivity or efficiency is an anti-pattern. If and only if a mature team is doing their own Sprint Backlog selection and planning, then a variation of the Pareto Principle is more useful. For example, if the Scrum Team is meeting its Sprint Goals more often than not (e.g. 80% of the time) then you can measure the Scrum Team's ability to deliver effectively based on that. However, many other factors impact the ability of a team to deliver, so that wouldn't necessarily be a direct metric either.
A raise is basically a way of rewarding individuals for performance and reducing organizational turn-over. Scrum is team-based, meaning the whole team either succeeds or fails together—no bike-shedding on whether "failure" is an agile concept or not, or whether it's all just "validated learning," please.
It you want to reward the whole team based on their ability to deliver, and assuming that this is in fact a fair representation of the team rather than a butterfly effect of the overall process, you could certainly tie raises for all the team members to their effectiveness.
On the other hand, if you want to reward individuals differently, you now have two problems:
Collaborative activities are inherently harder to measure. Doing pair programming, automation, or user story decomposition are all team-supporting activities. Will those performing essential support roles be rewarded for their contributions too, or will financial rewards only accrue to those whose contributions are most visible outside the team, e.g. writing the most lines of code or shepherding the most index cards across the kanban board?
To use an American football metaphor, glorifying only the people who score the most touchdowns de-legitimizes the contributions of all the other people on the team who made their accomplishments possible. What about the people who opened the way to the goal line with strategic blocks? What about the quarterback who made a series of unexpected but strategically optimal passes? What about the person who pretended to have the ball, ending up under a thousand pounds of opposing players so that the "hero" could run the whole length of the field unopposed?
When you think in terms of whole-team collaboration, it should be evident that treating raises as "prize money" turns individual team members into winners and losers. This changes the whole incentive structure from one that promotes team-based accomplishments into one that promotes individual gain. That will inevitably damage the esprit de corps that makes agile, whole-team approaches effective in the first place.
In short, you're trying to map metrics of individual merit onto a framework that is optimized for team cohesion and collaboration. Don't do that!
A raise is a financial reward. Rather than rewarding individuals, reward the team. You don't even have to wait until some annual review to do that. As some examples to consider:
In short, the notion of individual meritocracy is not itself antithetical to agility. However, the notion that you can measure individual contributions within a collaborative process is problematic at best.
You can't fix this on your own. It's an organizational and organizational culture problem, and must be fixed at the organizational level. The team can and should work with the organization to find a better process. Give them a seat at the table with the parts of the organization involved in this process, and give them the opportunity to work out a fair—"fair" being whatever seems fair to both the company and the entire Scrum Team—solution to what is not at all a simple problem. Scrum is based on empiricism, so be willing to experiment until you find out empirically what works best for this team in this company!
If you can, discard the notion of individual pay raises in favor of whole-team rewards. Otherwise, the organization must revisit how it defines merit and what they are actually trying to incentivize, and align their financial reward system based on that.
In most cases, raises are retention tools rather than rewards. Create ongoing incentives rather than annualized ones, empower your teams, and make the team a great place for people to work, learn, and grow. Money certainly matters, but it isn't the only retention tool you have. Make sure that the organizational goal (retention) is aligned with the team members' individual goals and you'll end up with a better retention tool than if you try to create an individual hierarchy of meritocracy within a flat ensemble group.
Please do not do that. You will only undermine the framework, the incentives to collaborate, and the sense of collective ownership and commitment that is at the heart of any effective framework that fosters agility.
I agree with Bogdan's answer. The only caveat to that is whether the velocity metric is tied to a performance fee in the contract, whereby if the contract is awarded an extra fee for great performance, I would share that fee across the team by way of a bonus. That is not unlike normal profit-sharing bonus programs.