My manager has recently really been pushing to use velocity as a target and measure of productivity. We are currently working at an average velocity of 50 story points. My manager wants us to increase it by 40 percent to 70 story points (with no increase in team members). If we don't achieve this increase he wants us to deliver a full break down explaining why.

The whole idea of measuring team performance by velocity and using it as a target seems wrong to me, but I am finding it difficult to explain why. Any help? Why isn't this the right way to measure and incentivize productivity?

Inflation can undermine velocity

Well, it's perfectly simple to increase velocity by 40 percent—just add 40 percent more points to all your estimates and do the same amount of work.

Given that this is so, it should be apparent why using velocity as a target is wrong; it just encourages inflated estimates.

A less glib answer is that your estimate already assumes you are going as fast as you can while doing everything correctly. The only way to really increase productivity by 40 percent is either to work overtime or to not do everything correctly. Both of these speed things up in the short term, but slow things down in the long term. And the long term in this case isn't very long, a month at the outside. The optimal long term strategy is to never go faster than your sustainable pace.

Peopleware is an often cited classic that talks eloquently about the issues of trying to force programmers into higher productivity. But in general it won't be easy to change the mind of a manager that is going down the path that yours is. Your project may well be in trouble—this is certainly a red flag.

Play politics

TL;DR: Velocity is very useful for estimating schedules or generating planning values, and can also be a meaningful detective control for assessing process bottlenecks or changes in team capacity. It is not, however, a valid measure of productivity.

When velocity is confused with management targets

"Velocity" is a range that expresses a team's average capacity over some historical period. It is a statistical analysis of past performance, which can then be used to project probabilistic estimates of future workload capacity or cycle times. This is in stark contrast to a "scheduling target," which is a managerial objective that sets a timeline or goal for planning purposes.

Experienced agile project managers know that the proper use of velocity is to determine whether a team has the sustainable capacity to meeting management-defined scheduling targets. Sometimes the answer is yes, and everyone is happy. Sometimes the answer is no, at which point the iron triangle forces business decisions about scope, cost, time, and quality.

Evaluate your political options

We have an average velocity of 50 story points...I have been asked to increase it by 40 percent to 70 story points (with no increase in team members).

Assuming that your estimation practices are sound and that your velocity is reasonably stable, your manager will get no joy from adjusting the estimate scale or setting management targets not based on historical performance. As you correctly point out, this is fundamentally a capacity problem.

The capacity limit may be related to the number of people on your team, or it may be a limitation of your organizational processes. Of course, adding more people doesn't always add actual project capacity either; see Brooks' Law for more on this common misconception.

The problem you face is political. From the tone of your post, it sounds like your manager wants to see an increase in productivity without making any actual changes to the team's underlying capacity. The solutions are therefore also political, and largely educational in nature.

If you are a Scrum shop, ask your Scrum Master to address this issue through the appropriate framework channels. Backlog Grooming and Sprint Retrospectives are often the ideal inspect-and-adapt opportunities for this particular issue.

If you're not a Scrum shop, you must decide what the proper way to address your concerns are within your organization. If you're on good terms with your manager, you might even loan him a copy of Agile Estimating and Planning for the two of you to discuss over lunch.

If all else fails, prepare for a death march by brushing up your resume and doing your professional best until the project implodes. 68 percent of IT projects fail; unless management targets are solidly grounded in organizational capacity, yours will probably be one of them.

Look elsewhere to improve performance

My experience is that it has been very, very hard to increase the actual velocity of a team, given that neither the team, the problem domain, or the technology stack change.

Where I have been able to achieve increases, it's been a matter of:

Cleaning up technical debt by ensuring that everything is running the right (not necessarily latest!) version, that the code is well-factored, and that there is no redundancy in the system (duplicated code, unused code, etc).

Improving practices by pairing where possible (yes, I've found that increases velocity), taking the time to refactor aggressively (ditto!), and being ruthless about scope and focus.

Finding and/or buying the best tools for the job (e.g. ReSharper for .NET is worth its weight in gold, Airbrake and Splunk for Ruby development, etc).

I agree with others here who say that your manager asking for an arbitrary increase in velocity is a red flag. I would be looking for another job as a high priority.