Well, it’s perfectly simple to increase velocity by 40% – just add 40% 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% 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 talks eloquently about the issues of trying to force programmers into higher productivity , and is an often cited classic. 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.

As the comments have pointed out, the request is obviously wrong the way it has been put. But he’s not really wrong to want to constantly improve productivity. As a rule, that is what managers strive (and are evaluated) for.

That said, managers are always looking to improve performance, and Scrum and Agile is all about being adaptable. While velocity is a measure of your current sustainable pace, you shouldn’t sit back on your laurels. Scrum has a place for evaluating and changing what works and does not in your process: the retrospective. If you take advantage of that and adjust your process, productivity (and possibly velocity) should go up.

So, are you looking (in your retrospectives) for ways to become more productive as a team? Is there anything in your sprints that regularly consume a disproportionate amount of effort? Can it be addressed? It probably won’t give you a 40% increase, but 5-10% is a start, no? Every sprint you should look for bottlenecks and address them. Eventually, you may get close to the goal he’s set for you.

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% 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% of IT projects fail; unless management targets are solidly grounded in organizational capacity, yours will probably be one of them.

I’m not understanding which role your manager has in the Scrum team? Is he a coach? Is he a product owner?

If he is inside the team like a coach or such (he works at a development task) you may ask him why he undervalues his own productivity, because it seems that was not the case for other team members. If he believes he can personally assume 30 story points more every iteration, let him show it.

More probable: he is outside the team, maybe the product owner? If so he should understand making such a stupid request he just stopped agility.

A basic rule is that the product owner sets the goal while the team sets what can be done in an iteration. Not doing so leads to the classical and well known iron circle: resources, velocity, features. Pick two! You can’t choose three of them at once (and remember: quality is not an adjustment variable, trying to cut corners through low quality will make things even worse).

If he doesn’t want to change the current goal, maybe a 40% increase in productivity can be reached by recruiting more people for the team? Maybe investing in some advance training for some team members? Teams may also gain velocity over time through continuous improvement, but certainly not by arbitrary decision.

Trying to change the velocity of a team is like trying to change the size of a room. It can be done, but basically you need to change the room.

Don’t you have some Scrum Master, or some other people around with basic understanding of Scrum who could explain that to him ?

In this case, the manager has turned the wrong direction after getting an honest and faithful estimate from the team. The manager is supposed to turn to the stakeholder and let them know that their requirements cannot be completed in the time requested. The manager / analyst should then prioritize which of the features MUST be included and the others which can wait (if even only a couple weeks). If the stakeholder is being unreasonable, then it might require higher up managers to get involved, which can generally be challenging and require a whole other set of discussions.

If i was in your shoes I would come up with a detailed case as to why the project IS going to take as long as was estimated. Also try to identify low return items. Find the items which don’t add much value and require substantial programming efforts and make a case for removing those from the sprint. Also come up with an iterative approach which delivers “X” on “Y” date and make sure that it’s feasible, then come up with a follow up iteration which will get them the remaining items.

Basically, someone needs to tell the stakeholder what they can expect to receive by the deadline and that it includes the majority of their requirements. and that by the following release they will have the remaining items. If the customer is that unreasonable then upper management needs to be involved, the manager should be able make this happen.

However, if the customer was over promised, and no one has spoken up until now it will be an uphill battle. This is not an uncommon situation unfortunately.

It sounds like you face two issues.

The part about measuring velocity that bothers you is probably that the measurement is the cost. What you really want to improve is the value. Unfortunately, measuring the value of software is notoriously hard and subjective. Still, even an imperfect and subjective metric can be useful. It could be that the real issue is not that your team needs to write more code, but that the the stories need to be more valuable.

The other issue is that based on your account, your manager expected a 40% increase in productivity. It wasn’t stated in your question the context of this request. It could be a good-natured if wishful desire for your team to improve. Or it could be a not so subtle indication that your manager believes that your team is under-performing.

edit: Based on your comment, the situation looks bad. It sounds like your company is laying the groundwork to fire you and your team (maybe your manager too). I suggest that you look for another job.

Fire him. That is to say, go over his head and explain that he has lost all trust of his team, and explain he is no value to the business. Explain that managers with this level of incompetence are far easier to replace than the team below.

There is no good reason to put up with such a manager, but that should not automatically mean that the developers should resign. There is not necessarily something wrong with the business, just with this one individual. Fix that problem.

And to preempt any shushing from upper management, make it clear that this is not a forgivable mistake. It signals that the responsible manager has no understanding of the team he is managing. That does not lend itself to fixing, nor is there a need to in the current labor market. Managers are eminently replaceable just like sports coaches. Owners don’t fire teams.

Now, this might look like a strategy that can backfire. But consider: if upper management sides with your manager regardless, you’d already be in a losing position anyway. So, if you only consider the situations in which you’re not already in that losing position, the outcome will likely be far more positive. The real risk is that upper management just fires the whole team, including the manager. Only you can estimate that risk. Apparently your output is wanted, else they’d not ask for more of it, but at which price?

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

Where I have been able to achive increases, it’s been a matter of:

• cleaning up technical debt; 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; 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.

Your manager is asking (or telling) your team to work extra hours. While removing bottlenecks and gaining efficiencies may improve your velocity somewhat, the only way to get that increase (40%) is by working longer hours, becuase you need to stuff in more units of work in that time period.

Let’s take a scenario.

For a two week interation lets say 10 days. Utopia would be 8 hours a day, with a story point being abstracted to a work day. So, from the top, your velcoity would be 8. But, relistically people are probably getting in 6 good hours a day with email, meetings, bathroom breaks, etc. So now your at a 6 per developer. So your baseline is 6. Let’s say you want people to work overtime, now there at 10 hours a day. So, that would be 10 velocity points per developer.

Your velocity will always fluctuate, maybe it was low because you had to deal with a lot of bugs during that iteration, maybe requirements were missing, maybe someone got sick for a few days. Maybe it was high because work was overestimated or your team put in extra hours.

But if your at a stable 50, really to get to 70 will require extra hours.

The problem with velocity is that it is a dependent variable, a measured output of your development process. Demanding to increase velocity 40% is like trying to get to work sooner by yelling at the cars to go faster. Velocity increases by feeding more fuel and air into the engine or getting a faster car, plus finding a route with less traffic.

Working more hours doesn’t increase velocity if you measure it properly, say in feature-points per developer-hour. It only works if you measure points per day and then redefine what a “day” is in mid-measurement. This provides only the illusion of speed.

An increase in velocity requires improving the independent variables in the dev process; faster computers and compilers, more efficient build system, better design process, more capable developers, better workspace, super-duper motivation. A 40% improvement would require very significant changes.

Ask if your manager would consider co-locating your team in enclosed offices around a common workroom, buying the team all-new dev hardware, or hiring a couple of really senior devs to mentor the team if that would get him his 40%. If there are no resources available to improve the inputs to your dev process, that pretty much rules out sincere interest in improving. This leaves reverse-engineering your manager to figure out what is really motivating him, which would be the subject of a whole ‘nother thread.

Well, I’m a bit surprised that the other answers take the boss’ request seriously. Someone who demands a 40% increase in productivity doesn’t know the first thing about software development.

I still enjoy reading Phil Factor on this topic:

There are two basic routes into IT management. You can learn your
trade through blood, sweat and tears and work your way up the ladder
gradually, based on the credibility you’ve gained from hard-earned
technical know-how and successful projects. Alternatively, you can don
a sharp suit and tie, learn the lingo, and smooth talk your way to the
top.

Both routes seem equally effective. Dealing with the latter breed
can certainly cause some moments of dismay and incredulity… despair
even… and some of that is documented in these stories.

However, it’s easy to become sad and embittered when one
encounters technical incompetence in positions of power, and to tar all
managers with that same brush. Phil advises against it. Most managers
work hard and contribute well to the company, and even poor managers
can be trained up to the required standard, if you just follow a few
simple guidelines. It’s part of your team responsibility to help your
manager function in a way that will benefit all.

Ultimately, if you can’t train them, get them promoted, or avoid them,
maybe you can learn to love them just for their unintended
contribution to the rich comedy of the workplace.

The advise not to become “sad and embittered” is the best you can get. Don’t fight a technically incompetent boss over technical matters. He’ll just see that as a personal attack.

Your manager has misunderstood the use of velocity. It is not a metric and it is not a target. Its purpose is the calibration of the team workload per sprint.
If you think about it, your velocity emerges from a best guess, which you remeasure after each sprint. Usually as time progresses, it should become somewhat stable. But that doesn’t change the fact that it is a byproduct of what your team is actually doing: creating value for your customers.

The reason why it is wrong to use it as a target and/or a metric is because that would make it a vanity metric. It would look good on paper, but it would do absolutely nothing to reflect wether or not your products are fullfulling your customers needs. And that is what is most important (I hope).

Regarding my experience and going straight to the point.

First, you could inflate the estimation but it doesn’t mean you’re doing more.

Second (premise: without inflating, just focusing in team velocity),

Try to find the skills inside your team. Are they working on what they’re best? Do you need an systems architect to make the difficult decisions regarding construction of the application and complex things? How the team is spending their efforts? They’re spending time researching solutions for their problems, refactoring, making business decisions or what?

Are they comfortable, focused and estimulated? What’s going next for them?

This is not “i’m pushed on the limits”… it is more like a question for the whole team “Are we on the limits?” and “How can we push the limits?”…

I have leading high performance teams (for first construction and/or migrations)… the motivation of the team is the key of success… and planning how would the base of the application shall be is essential. Sometimes I or a teamate get the role of Systems Architect and decide how and where the “thing” should go.

Sometimes when I see that my teamates are losing efficiency, I try to break and invite them to get out for a drink beer, or something they like. This solves any conflicts and on the next day they’re focused again.

SELLING…

If explain the reasons you can’t increase the velocity is hard, use the ROI.

Scrum focus on what’s most important for the client. Theoretically the most profitable tasks.

If your problems is regarding selling the development effort, what do you think sell whats the ROI of development effort instead directly convert story points to the “price”. If you can proof that your team works with a high ROI, who’s going to question you? Also, every team has its limits if the team has found its “confort size”, try month-by-month a slightly increase, if they couldn’t finish all tasks this is (probably) the limit.

Show the history of the tasks, the profit revenue (if available), the story point you have used, and show that PRODUCTIVITY ISN’T THE TEAM EFFORT is a calculation determined by the team to evaluate the complexity and perhaps the time to get something done