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?

  • 21
    Velocity is arbitrary. What stops a team just inflating their estimates by 10% every year? Commented Aug 30, 2023 at 19:47
  • 17
    This precisely what Goodhart's law is there for, by the way ("any measure that becomes a target ceases to be a good measure"). Commented Aug 31, 2023 at 17:20
  • 4
    If you want an actual good metric to use, look at profit sharing. Final, hard results are much harder to game, Goodhart's Law-style, than intermediary steps along the way. If the only way workers get a big bonus is if the product is a big success, then that's what they'll try to work to produce. Commented Aug 31, 2023 at 20:04
  • 1
    would the converse hold true? (i.e. a pay cut due to reduced velocity)
    – Zephyr
    Commented Sep 1, 2023 at 1:27
  • 5
    Even if velocity wouldn't be arbitrary, what would stop the team from minimising QA and completing as much as possible without the quality. Commented Sep 1, 2023 at 7:44

6 Answers 6


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:

  1. The tool becomes useless; any forecasts and plans relying on it will drift away from what the team can potentially do. Because...
  2. People start gaming the system. You will start with 100 story points per sprint and by the end of the year you will get 500 story points with no change in team performance or delivery.

And since a picture is worth a thousand words, I'll leave you with a Dilbert sketch on a similar note: enter image description here

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.

  • 6
    Even if the team routes around this by adding "enabler" stories for these things to get their free money, that's harmful because changing the meaning of velocity hampers its use as a capacity predictor. Commented Aug 31, 2023 at 6:54
  • 2
    Not only are teams going to try to offload anything with low story points to effort ratio, anything with a high story points to effort ratio will will be in high demand, and will be assigned according to who games the system the best, rather than who can do it most efficiently. Commented Sep 2, 2023 at 4:52

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 != Productivity

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.

"The Goal of a Sprint is to Complete the Sprint Goal"

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.

What's a Raise Intended to Accomplish?

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:

  1. You are actively working against the notion of collective ownership and commitment that is at the heart of Scrum and other agile frameworks.
  2. You need a non-proxy metric that is based on individual merit rather than team merit, but will therefore be biased towards some types of team contributors more than others.

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!

Fix the Company Culture

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:

  1. If a team delivers a working product ahead of schedule, they've saved the company some amount of money. Why not provide a prorated share of those savings equally among the members of the team?
  2. If your costs go down because the whole team has improved product quality or takt time, then why not reward the team with a prorated share of the cost savings?
  3. If you sell more units because of the team hitting their forecasts more often or being more adaptive to changes in the market, why not create a profit-sharing plan?
  4. (Not recommended, but...) Scrum Teams are supposed to be self-managing. If there's money to be distributed as a reward, let the team figure out what they consider a fair way to distribute that reward. They are in the best position to know who has contributed the most to the team's success, after all. Let the team decide who should get what share of the bonus money.

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.

  • Without an ability to reward individual contributions, how do you recognize personal development and career experience? How do you recognize the individuals that develop skills that are useful to the team, vs those that that stick to what they know, even when it isn't appropriate? How do you recognize that some team members have more skills than others and are capable of delivering more value to the team? Commented Sep 1, 2023 at 23:59
  • 1
    With a purely team based system, how do you avoid incentivizing the top performers to leave, as their market value is based on their individual value, whilst the existing pay will be based on the average of them, and the lower performing team members they worked with. Commented Sep 2, 2023 at 0:02
  • 1
    Delivery of the sprint goal has some bad side effects as well. It encourages conservative sprint goals that salami slice the value, minimizing value delivered per sprint to the minimum the team can negotiate. This happens because including more value in the goal decreases the chance of delivering the goal. Commented Sep 2, 2023 at 0:12
  • 1
    Its the commentary about individual meritocracy vs team rewards, which this answer delves into, despite that not being the question. Whilst ignoring the issues about members of teams being individuals, who have there own place in the wider market. Commented Sep 5, 2023 at 11:01
  • 1
    Todd, thanks for improving my edits. I know very little about American football (I gather it's a bit like rugby football), but that doesn't matter - even I can understand the analogy! Commented Feb 15 at 15:32

You've had some good answers and I agree with them. More sensible would be to find another measure of real value delivered by the team, for example OKRs based on deliverables or satisfaction surveys of users or stakeholders.


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.

  • 3
    I've seen this in outcome based contracts. The client tries to look at the team and tie them to measurable outcomes. Velocity is the first thing they go for. And often the last... because why bother with something else? You have a simple number that needs to sit within some arbitrarily selected ranges. And sure... you can also reward extra performance when the number goes above the upper limit. But all those things still don't mean anything, because that's not what velocity should be used for.
    – Bogdan
    Commented Aug 30, 2023 at 20:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.