Velocity Isn't a Productivity Metric
In other words, when they are left to decide how much is too much, they will say commit to 40 points, whereas when pushed to do 60, they will deliver 60.
If you are managing to a velocity metric, then you're Doing Scrum Wrong™. Velocity is a capacity metric, and has no utility in measuring a team's productivity. Even if it were, adopting an agile framework like Scrum wouldn't necessarily make teams more productive.
What velocity should do is achieve a stable, sustainable state. A sustainable velocity make process inefficiencies more visible, so you can address them. It can be used for secondary functions like estimating lead time only when:
- The range of a team's velocity is relatively stable.
- The work to be estimated is granular enough (and familiar enough) to avoid guesstimating about "unknown unknowns."
Trying to maximize velocity metrics is a an anti-pattern. Instead, you should increase communications and transparency around your Sprint Goals.
Leverage Sprint Goals
When you misuse velocity as a management metric rather than for its intended purposes as a planning tool and detective control, you're defining a target level-of-effort by management fiat. As a result, you're practically begging to be given inflated estimates by teams that try to meet these "visible effort" goals. Don't do this to the team, your project, or your company.
Instead, you should switch to an increment-based metric where a central coherence is either "done" or "not-done." The Sprint Goal was designed for that purpose, and should be what you're using to determine whether the team delivered what it planned to do or not.
The purpose of a Sprint isn't intrinsically to put in a lot of effort, do lots of things, or perform lots of tasks. The goal of a Sprint is to deliver the Sprint Goal! As such, the framework actually requires that each Sprint have a central coherence that defines it and ties all the work for the Sprint together. This is often a feature (or set of smaller features) that forms a logical increment of potentially-shippable work. This goal is set internally by the team, and is not just another way to impose a management target.
At the end of each Sprint, the Scrum Team and stakeholders use the Sprint Review to inspect the increment together. The Scrum Team then feeds the results of the Sprint into the Sprint Retrospective to improve their processes, and into Backlog Refinement and Sprint Planning for further work.
From a management perspective, a team that meets its internal Sprint Goals more often than not lends predictability to a project. A team that misses its own Sprint Goals more often than not may need additional resources (like money, staff, or a strong agile coach) to succeed.
There is no silver bullet to managing performance with Scrum. While the transparency, visibility, and communication enhancements of the Scrum framework can certainly increase the efficiency of mature development teams, it will not allow companies to hire junior resources or mediocre people and wring anything more than predictability from the process.
Obviously, there's no way for anyone outside your company to determine if the inability to reach your project targets is due to poor target-setting by management, poor performance by teams or individuals, or poor agile release planning. It's important that your management team works closely with the Product Owner and Scrum Master to ensure that all stakeholders agree on the current release plan, and that the plan is continuously updated based on the current state of the project.
If management defines the release plan, rather than allowing it to be an emergent property of the agile inspect-and-adapt cycle, then this is unlikely to be successful. There are a lot of reasons for this, but of particular concern is the fact that an off-shore team is often not just a team but also a vendor. A vendor/client relationship within an immature Scrum process is unlikely to result in the level of honesty and transparency required for the Scrum Team to push back and say, "We can't reliably meet those goals."
On the flip side, if you have a mature agile process, but your Scrum Team can't provide you with the level of productivity you need, you will need to:
- Revise your expectations downwards.
- Train and improve your existing team.
- Replace your existing team with another team or vendor.
These choices generally require increased budget and run-time for the project, so they are a cost of doing business rather than a cost-free activity. Nevertheless, they are among the primary choices you can make in such situations.