Team velocity declined after legacy declaration



  • 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.


  • QA Engineer

    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.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2