I am the manager and I am struggling with a declined velocity. I have tried to discuss with the team what is going on, and they say they got better at story point estimation. But I suspect they are not motivated.

A few months ago, the director announced that the company planned to phase out the software the team had been working on and replace it a different product from the market. He said there were no timelines yet for the sunset date and it was not their intention to leave users without alternatives. It is not clear if the team will have any role in the new product, so their future is uncertain.

Ever since the announcement, the velocity has declined by up to 50%. I suspect the team are either interviewing or ramping up their skills to prepare for their next job. How do I motivate them to restore their velocity?

I know it is not common for management to rely on velocity as a measure of productivity. But in this company, velocity and individual points are how teams and individuals are evaluated.

  • 4
    Velocity should be used as a factor in estimation, not as a team evaluation metric. Deteriorating velocity is a sign that something is wrong in the environment, and that productivity is negatively affected. You already know what's wrong... There are many ways management can destroy worker's motivation and productivity, developers are not machines, and even machines would react negatively when mishandled. Telling a developer that his work isn't needed anymore has the same effect as throwing a wrench in the gears of a machine... Commented May 19, 2020 at 14:00
  • 1
    If you want to double the velocity, double the estimates on the work that the team picks up. Commented May 21, 2020 at 15:08

4 Answers 4


Stop Abusing Velocity

I know it is not common for management to rely on velocity as a measure of productivity. But in this company, velocity and individual points are how teams and individuals are evaluated.

So, you know the company is doing the wrong thing and following an anti-pattern, and yet you're expecting a different outcome. That isn't reasonable.

More importantly, your company is making the cardinal mistake of treating velocity as a proxy for productivity, rather than as a planning value or estimation tool. You already know this is an anti-pattern, so don't do that either.

Examine Your Process and Your Messaging

From a process perspective, you have a couple of options:

  1. Hold a retrospective to examine the process.

    It seems extremely likely that your application is being sunset (eventually) because of technical debt, product complexity, or other systemic drags on development productivity. Deciding a priori that it's the developers' fault is another anti-pattern.

  2. Identify any other root causes.

    What else has changed in the environment? Has funding been cut? Have tools and equipment been re-allocated? Is there anything else standing in the way of productivity? Ask the team. Investigate. Find out!

  3. Hold senior management accountable.

    If there's a genuine decline in productivity (rather than simply a reduction in a capacity planning metric like velocity), and if it's attributable to management's communication or de-prioritization of the project, then it's up to management to fix the problem.

    In business, executives asked to stay on a sinking ship are generally given bonuses or incentive pay to reduce "flight risk." Warm fuzzies, gamification, or pizza parties will not fix a management message of:

    You will all be out of a job at some indefinite time in the near future.

    Your developers are people, and if your organization treats them as disposable or fungible assets then they have no claim on their personal loyalty. If that turns out to be what's actually going on, senior management must fix it in a constructive way, rather than flogging everyone in the vain hope that morale will improve.

Personally, I suspect #3 is your likeliest problem, but you need to ensure you correctly identify the real root cause and eliminate all other process problems before you start tilting at organizational windmills. Regardless of why the process is now broken, a Scrum Master or project manager is responsible for communicating the problem upwards so that senior management (who collectively own all risks and outcomes, regardless of cause) can resolve any issues that the team can't resolve for itself.

  • Thanks for the brutal honesty! I am aware that it is anti pattern. I did tell my director that productivity should be measured against sprint goals! His response was that he is not convinced that it is improper, just because other organizations choose not to do it, it does not mean that it cannot be done by us!!. We actually have organization wide velocity goals - meaning senior management decided how many points on average each team should be delivering and one of my jobs is to keep the team on that trend! Horrifying I know, but how can I, a single individual fight an entire organization? Commented May 20, 2020 at 1:51
  • @user6284097 Educate your director. Invite him to hire a well-respected agile coach for a tune-up of the process. Or possibly just dust off your resume and start quietly looking for another job. Even in this economy, you're likelier to find another job than you are to survive a death march or solve a policy-based bungling by unaccountable leadership. It's your career; take ownership of that if nothing else.
    – Todd A. Jacobs
    Commented May 20, 2020 at 11:17

You should definitely be careful. Velocity is a subjective measurement. As teams stabilize, it usually reflects productivity with some degree of accuracy. However, it is not productivity and it can move independently of productivity.

That said, it is possible that the team is right - their estimates are just more accurate now. If that is true, they may actually be more productive right now. As a leader in the organization, it may be your job here to stand up for them.

Also, your suspicions may be right. Demotivation can have a huge impact on anyone. As a manager, how have you explored this existential threat with the team? Have you raised your own observation about the uncertain future to the director? I don't know if this will have any impact on velocity, but if you are observing people being anxious, helping them resolve that certainly won't hurt the team.

Ultimately, velocity is a lagging indicator. Trying to change velocity is sort of like moving the needle on a speedometer to make the car go faster. Your post suggests that you are observing the team and identifying multiple hypotheses for why circumstances are what they are. That's exactly what you should be doing - see that through.


Your boss also erred by telling the team that their product was going to be scrapped without apparently giving them the promise that they wouldn't be. Therefore, for what should be perfectly obvious reasons, the developers stopped caring about a product that the company no longer cares about, and put their job searches into high gear. Very soon you won't have a team left to manage. (Maybe you should be putting your own job search into high gear, too ...)


Bear in mind that once velocity becomes a productivity metric it can EASILY be gamed - just scale up the complexity points for each feature/story! As stated above, the only real productivity metric is delivered working features.

In your given scenario though, it does sound like your team is voting with their feet...

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.