# Is a large increase in velocity realistic in a Scrum environment?

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% 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?

• wow. manager either doesn't understand what velocity is, or thinks the team is slacking. or both. At the next planning meeting, commit to 70 points and let the team tell him the failure risks that will cause Commented Sep 16, 2013 at 18:31
• It seems like such an inane request, that I would like you to ask him why he thinks this is possible - if you're already giving 100%, does he expect you to give 140%? What if you just make sprints 40% longer? Commented Sep 16, 2013 at 18:45
• Velocity is supposed to be a measure of how fast you can get things done. If your velocity and story points are at all accurate, this is telling you that you can't get the entire backlog completed by the deadline. The rational thing to do is to accept reality and either cut things from the backlog or else prioritize what's there so that what you do get done is the more important stuff. Or you could change the deadline to something realistic. Commented Sep 16, 2013 at 21:30
• Ask him for a 40% increase in salary if you achieve those targets, then increase your estimates so you get the 40% increase. Commented Sep 16, 2013 at 22:24
• Isn't that rather like asking a marathon runner to suddenly run the marathon in 1h25m instead of 2h? Commented Sep 17, 2013 at 9:13

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.

• I strongly believe that there is no "quick and dirty". "Dirty" always makes me slow - even in short term. Commented Sep 16, 2013 at 20:45
• @Paul - I thought it was good. But the advice in it can mostly only be followed by managers, and the ones that could benefit from it probably won't read it. Nor will reading it necessarily change behavior.
– psr
Commented Sep 16, 2013 at 21:41
• And if you agree and really increase the velocity by 40%, it will look like to others that you and your team were not working at your best. The professional way to handle it is give a straight answer: "No, can't do.". Another book reference about it: "The Clean Coder" by Robert C. Martin. Commented Sep 17, 2013 at 22:26
• axosoft.com/blog/wp-content/uploads/2012/08/… Commented Sep 18, 2013 at 14:15
• "your estimate already assumes you are going as fast as you can while doing everything correctly" This is probably an incorrect assumption. We can always continue to improve and optimize. Teams should never assume that their stable velocity indicates that they can't get any better. But they need to look at their entire process systematically and look for minor process improvements. Commented Feb 20, 2018 at 19:30

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.

• +1: This is a good way to describe it to the manager. You can't artificially push velocity up, but you can look back after each sprint and learn what you can do to be more efficient next sprint. Commented Sep 16, 2013 at 21:44
• Odds are that removing the manager's overhead (forced meetings, filling out forms, etc) would probably give you that 5-10%, easily. But how to convince him?
– AviD
Commented Sep 17, 2013 at 10:17
• I think your answer represents a misunderstanding of velocity. It is not absolute metric, its an average measured over the life of the project. What is more velocity points themselves don't represent work done but rough measures of complexity. They are also averages themselves, and a low point task may require more time than a higher point one. It seems a little meaningless to ask for "more" and represents a fundamental misunderstanding. The manager is basically asking for a fixed deadline. Commented Sep 17, 2013 at 11:22
• @RicardoGladwell - When I said "the request is obviously wrong", I was acknowledging that this was an incorrect understanding of how story points work. I was merely suggesting that what the manager really wants is for the team to improve productivity, and Scrum does provide a means for doing that. Also, there are different takes on what story points represent--complexity being one of the most common. Most teams I've worked with have made them correspond somewhat with level-of-effort. A simple task with a lot of quantity is no longer considered simple. Commented Sep 17, 2013 at 11:32
• You do mention that an increase of velocity of "5-10% is a start" but this seems to share the manager's misunderstanding of what "increasing velocity" means that I outlined. Commented Sep 17, 2013 at 12:55

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

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.

• quality is not an adjustment variable: that's why we speak of iron triangle, not iron square. In other words, when somebody tries to lower "quality" it wreaks havoc in delays (longer deliveries), scope (features are not working and thus not realesed)... and ressources (developpers are frustrated and leaving). Nice answer beside that minute point. Commented May 5, 2014 at 12:14
• @kriss Quality can, indeed, be part of the triangle. It is sometimes considered part of "scope," or in some triangles it is an actual vertice indicating it is a primary constraint. See the blue triangle within the PMBOK Star as a concrete example, or Evolution of the Project Constraint Model for some details on this issue. Please bring this up on PMSE for more. Commented May 5, 2014 at 14:13
• this is a discussion I already had with fellow agilists. Summarily what we disagree on is that PMBOK is a valid Agile ressource. It originated with the waterfall model and is orthogonal to agile. It's mostly compatible, but there are still some issues. Considering Quality as an adjustment variable is one. As I see it (and I'm not alone) using (trying to use) Quality as an adjustment variable breaks the whole Agile process. But it should be a question of it's own. Commented May 6, 2014 at 9:24
• Question posted here pm.stackexchange.com/questions/11489/… Commented May 6, 2014 at 10:07

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.

• "honest and faithful estimate" may be the problem. Commented Sep 17, 2013 at 12:24
• @JeffO - Could be, that's why I recommended making the case to justify the estimates.. when they try to do that they'll either realize they inflated their estimates or that they truly dont have the capacity Commented Sep 17, 2013 at 15:48

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.

• Unfortunately it was a serious request, phrased along the lines of I see no reason why you can't achieve this (but am not going to tell you how!). So the implication is that he doesn't believe they are working hard enough or are not as competent as they should be. It then got worse when I was away on holiday and the Product Owner told the team that there would be serious repercussions if they don't achieve it. So I now also have a very concerned team (who I genuinely believe to be a great team) to worry about too.
– P2l
Commented Sep 16, 2013 at 21:43
• +1 for "get out of Dodge". Sometimes it's the only way (though the less often the better). Commented Sep 16, 2013 at 22:22

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?

• In other words, put your hands up in the air, wail, and throw a fit. This kind of attitude never solves problems. There are much better ways to handle the situation. Commented Sep 17, 2013 at 18:06
• No. Wailing, or throwing a fit are drama actions. That can be ignored. What I propose is an ultimatum. Either this manager goes, or the team goes. No drama, only cold business logic. He's not fit for the job, and it's the task of upper management to act on that. But their preferred option might be to ignore the situation, if you allow them to. That is why you need to take away that choice. Commented Sep 17, 2013 at 23:03
• @nathanhayfield Typical? I think the team would be made up of a range of personalities and people. Lazy ones should be address individually not a blanket request to the team. Commented Sep 18, 2013 at 3:09
• @MSalters There are a lot of people in different layers of business that will not understand certain things. The correct approach is to mitigate conflict and educate everyone invovled. Maybe this manager doesn't understand Agile, but they may have other redeeming qualities (which might be way more important). As a professional, you should be making the best of every situation and work with every type of personality - because that is actually constructive and helpful in the longterm. Doing what you're suggesting doesn't scale. Commented Sep 18, 2013 at 13:20
• @MrFox: Direct managers are supposed to understand scheduling; in fact they are the layer most directly responsible for it. The team members are supposed to be subject matter experts and higher-level management are further away from the action. So this manager, in a position where he is making claims about schedules, proves he doesn't understand what is perhaps his most important task. If the job market was tight, getting a better manager might be troublesome. But today you can find someone better. Commented Sep 18, 2013 at 13:33

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.

• Well I think this sort of depends on to which management model you subscribe. Coaching Leader: a recognized expert who gets his hands dirty and teaches others how to get good, but generally remains "the Guru". Leadership Director: the "expert" who knows everything (or thinks he does) and just gives orders and tells people what to get done. Leadership by delegation: may not be the expert, trusts in their expertise and facilitates. Supportive Leadership: the cheerleader for the group helps build them up, motivational, persuades the team they can do it and helps them achieve it. Commented Feb 20, 2018 at 19:47

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

• as far as I can tell, this is already explained in another answer: "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..."
– gnat
Commented Sep 17, 2013 at 11:33
• @gnat part of it yes, though that answer says nothing about using velocity as a vanity metric, which is still important, because to many managers do stupid things based on proxy numbers. The OP said he felt that it was wrong, but couldn't explain it. I felt that the term vanity metric (from The Lean Startup) offered a good explaination. Commented Sep 18, 2013 at 7:57

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