Velocity is Killing Agility!

As I talk with companies around the world it’s clear that a significant number of them are still mired in the productivity, efficiency, and optimization mud. It’s easy to spot them because they are often maniacal about measuring velocity—team velocity, velocity across teams, rolling up velocity to an organizational level or even velocity per developer (yuck). Velocity is thereby killing agility. It’s the ultimate in applying a reasonable tool for the wrong reasons:

  • Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.
  • Focusing on volume detracts from the quality of the customer experience delivered and investing enough in the delivery engine (technical quality).
  • Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine.
  • Particularly for those parts of the business for which high responsiveness (a deployment cycle time of days or weeks) is critical, investment in the delivery engine is as critical as investing in new features.
  • Management needs to allocate resources between features and engine work and then create a product ownership team consisting of the product owner and technical leader to do feature prioritization.
  • Value (value points) and cycle time metrics will help balance the detrimental effects of velocity measures.

Over emphasis on velocity causes problems because of its wide used as a productivity measure. The proper use of velocity is as a calibration tool, a way to help do capacity-based planning, as Kent Beck describes in Extreme Programming: Embrace Change. Productivity measures in general make little sense in knowledge work—but that’s fodder for another blog. Velocity is also a seductive measure because it’s easy to calculate. Even though story-points per iteration are calculated on the basis of releasable features, velocity at its core is about effort.

While Agile teams try to focus on delivering high value features, they get side-tracked by reporting on productivity. Time after time I hear about comments from managers or product owners, “Your velocity fell from 24 last iteration to 21 this time, what’s wrong? Let’s get it back up, or go even higher.” In this scenario velocity has moved from a useful calibration tool (what is our capacity for the next iteration?) to a performance (productivity) measurement tool. This means that two things are short-changed: the quality of the customer experience (quantity of features over customer experience) and improving the delivery engine (technical quality).

Agility is the ability to both create and respond to change in order to prosper in a turbulent business environment. It means we have to build and sustain a continuous value delivery engine, not one that bangs out many features the first release and then rapidly declines in ability thereafter. The ultimate expression of agility from a software perspective is continuous delivery and deployment. Our goal should not be productivity, but to “Design and deploy a great customer experience quickly—again and again over time.” In order to respond to business, technology, and competitor turbulence in the market we have to focus on delivering a superior customer experience, building new features, and improving the delivery engine that allows us to deliver quickly each and every release cycle.

Compounding the problem, the Agile movement has focused on high levels of customer involvement—basically a good thing—but we’ve gone too far. A large number of Agilists decry that they can’t get organizations to focus on technical practices—but why should that be a surprise when we encourage product managers/owners to make all the priority decisions and then measure performance using velocity?  We have overcompensated for the lack of customer focus in traditional methodologies—by giving control of prioritization to the product owner/manager. The tendency has been to lump all work under the heading of “customer-facing” stories and assume we can convince product owners to agree to all the technical engine work that needs to be done. This is an over-correction from traditional projects in which months of technical work preceded any customer facing work (which was an even worse problem).

Product managers/owners understand prioritizing customer experience work, but they are generally not incented nor understand the technical engine work to be done. We need to create a product ownership team consisting of the product owner and a technical leader (which may include a quality assurance lead). Product owners are the customers of today while technical and quality leaders are the customers of tomorrow.

Imagine our software delivery engine as a high-powered jet engine in a fighter aircraft. What if we fail to perform adequate maintenance on that engine—it gets gunked up. What if we don’t periodically re-build parts of the engine? In software delivery we gum up the engine by: ignoring technical debt, delaying refactorings, disregarding automated testing, under-investing in continuous integration tools and processes, and in accepting long deployment cycles. These things are often considered “technical niceties” rather than keeping the engine running at optimum capacity.

In Don Reinertsen’s book, The Principles of Product Development Flow, he suggests the formula: Cycle time / Value added time = 1 / (1 – Utilization). Therefore, when teams optimize their process for velocity, they increase the amount of waste in the delivery process, and increase cycle time. Conversely, when teams optimize for cycle time, utilization (and thus velocity) goes down. There has to be a balance.

Business has moved from a world of periodic change to one of continuous change. In parallel to this, software development is evolving from project work (deliver software in a big batch and then maintain it) to one that is product oriented (deliver software in continuous releases). In order to drive behavior in the right direction we need to incorporate measures like value, delivery cycle time and technical quality metrics into our performance criteria. We need to calculate feature “value” points as well as feature “effort” points (story points). Cycle time can be an excellent measure because it depends on the software delivery engine working well, and, it’s a measure business customers understand. When we say, “Do we want new features or quality (or technical debt reduction, etc.)” it’s easy for product owners/customers to say, “of course new features.” Instead we need to say, “How do we need to balance new feature delivery with cycle time reduction?” [Note: Cost of Delay, per Don Reinertsen’s book, can also be a useful metric.]

This blog should not be interpreted as anti-velocity; it still has a place for capacity planning. The problem is the weight given to velocity and turning it into a productivity measure. Because it is easy to measure, we measure it. But even more important is measuring things like feature value, feature delivery cycle time, and quality measures (defects, technical debt, etc.). Delivering high-value features to customers should be paramount, but the focus should not be one-time delivery, but continuous delivery. The debate is not features or quality; it’s balancing delivering features quickly today with increasing our ability to delivery features quickly tomorrow—over and over again. Business responsiveness is a capability, not a one-time event. Supporting that ongoing need for business responsiveness requires a high-powered, well-oiled software responsiveness engine.

Note: Thanks to Martin Fowler, Jez Humble, and Ken Collier for their comments and ideas on this article.


    1. Another issue with the emphasis with velocity is that few people understand the underlying assumptions of calculating velocity (see for more.)

    2. Great post Jim! I agree 100% This is very much in line with a post I wrote on my blog a couple months ago in which I share my thoughts on some of the dangers of this high focus on velocity.

    3. I couldn’t agree more, it’s scary how quickly velocity gets twisted to suit a mere management purpose and loses it’s meaning as a tool. It is literally to the point where it is far more harm than good to most agile teams.

      That said it seems the dysfunctional businesses and teams are still the root cause in the end. I once attended in a SCRUM master training session (company provided, not specifically by choice) where the trainer said:

      “You can’t measure the relative performance of teams using velocity”

      To which the head of the product owner team (yes the product owners had their own team) responded:

      “Well then how do you measure the relative performance of teams?”

      Coincidentally I just had a similar blog post today which touched on velocity but focused on the downsides of iterations as well. Assuming you don’t mind the link in your comments perhaps you’ll find it interesting:

    4. Jim, I fully agree with this article! Velocity is a team internal metric which can help the team members to estimate and plan their work. Period. Using it by management indeed as you descrtibe distracts the teams from delivering value, which can never be the intention of managing agile teams.

      Instead of managing with velocity, managers should focus on thing like increasing the capabilities of their employees, establishing stable teams, and taking effective and timely decisions; enabling their teams to perform and deliver.

    5. Great Post Jim! I could not agree more.

      Best regards

    6. Thank you Jim. Quantitative measurements for complex work may have their place, but lend themselves to abuse when the fundamental mindset hasn’t changed. I am very worried when people try to learn Agile by focusing on the numbers.

      Regarding technical leadership and saying “no” to creating more technical debt, don’t we want that on the team itself?


    7. Sounds like command and control management finding a number and using it instead of their brains sadly I think they’d only find some other way of sabotaging things, it’s what they do. “Change the organisation, or change the organisation” (I think this was Martin Fowler originally)

    8. Great post and something I have been thinking for a while. I was once on a project where the whole team was dragged into a room and asked “How can you improve your velocity”, because we were going too “slow”. All the while I am thinking, isn’t the point to get the product the customer wants out of the door.

    9. Henry Miller says:

      I just made a similar argument to my boss, and he agreed to take off of his 2012 goals “create a consistent story point across teams.” However if I don’t provide him an alternative that gets him the answers to his real questions he will probably do this anyway. (It will fail, but at least he can say he made an attempt at something, and he can probably blame the failure on something else)

      Our real problem is we need to meet an external schedule. Our software will ship with the all new model year 2013 vehicles. There is a set of features that our customers demand – we will get beat up in the market if the 2013 vehicles are less capable than the 2012 (2012 used completely different software with technical debt so high we would not be able to add any new features if we ported that: for 2013 we have a ground up redesign). Scope and schedule is fixed, the only question price. My boss would rather not pay more people than required to get the job done, but if he can show that x more people today are needed he will get those people. We are all well aware that realizing we won’t make it one month before the deadline is too late to hire more people.

      Does anyone have any system (or ideas on such a system) that let us predict what it takes to get done in time?

    10. Artie Gold says:

      This is just another case of extracting a metric that seems to correlate with (the harder to define concept of) “success” — and then concentrating on maximizing that metric. The metric becomes more important than the true task at hand. You want to complete a lot of stories? Easy. Make the stories smaller. Hide a decaying infrastructure? No problem. It never comes to the top.
      But that’s why it’s all an art — no matter how important discipline and methodology might be (and they certainly help; they’re not enough by themselves).

    11. A humble proposal: maybe is time to abolish tge “velocity’ term and use one more related to capacity.

      Here in Chile I use “team bandwidth” as a better metaphor (not perfect) to indicate that this capacity must be trade with customers wisely and that we need to avoid overload them.


    12. It all comes down to the basic presupposition that productivity is something that can be prescribed and enforced.

      Velocity is a measure of what actually happens, not a bar for what’s supposed to happen, and that use of it goes back to the idea that, somehow, knowledge work productivity can be mandated.

      I don’t know if this comes from an idea that people could be more productive if you whipped them harder or what, but somewhere along the line, someone got the idea that the people managing the work should be able to dictate how quickly the work will be done.

    13. it is crazy that we are still having this discussion after 10 years. :)

    14. Insightful post Jim. I especially like “Our goal should not be productivity, but to “Design and deploy a great customer experience quickly—again and again over time.” ” I could not agree more.

      This is why I think Agile has set us back. I am not sure if you saw my recent post in the same subject.
      Agile Is A Cop-Out; What’s Next

      We are the same page.


      • Mike,
        I saw your post, although I don’t think Agile is a cop out, it is just maturing from where we started.


    15. Hi Jim –

      This is a great post and I do completely agree with the contents and the philosophy of not using Velocity as a productivity measure.

      However, I do want to understand when a client agrees to pay money for delivering a specific functionality and the contract is not a conventional waterfall based contract where we are signing up for delivering x-scope items in a scope matrix in a fixed time and a fixed price. Rather it is a “capacity” based where you are asking the client to sign up typically for a capacity who will deliver value, client does expect some metrics around it to make sure the money would be utilized correctly.

      If this metric is not and cant be velocity, what is the metric we can promise to someone who is spending money to assure him that he will assure him his/her money would not be wasted…

      Would like to hear your and other point of views here.

    16. I got confused with your third bullet point. Did you mean “we have gone from customer focus to product owner/manager control”?

      I believe a lot of companies still fail to be agile because they don’t see the big picture of the change that is happening in the business world.

      From your post:
      “a significant number of them are still mired in the productivity, efficiency, and optimization mud.”
      “productivity measures in general make little sense in knowledge work”

      Indeed many not to say most managers are still trapped in a factory work mentality even though they’re in a knowledge work reality. By confounding efficiency with effectiveness, they have a hard time moving their organization from being efficient to being creative.

      In another blog post, I think you wrote “Adaptation depends on Leadership and Collaboration rather than on Command and Control.” I also like your distinction between “Doing Agile” and “Being Agile”. To me, the being precedes the doing and as long as managers will try to do agile while deep inside they’re still coming from a Command and Control mindset, they’ll keep on misunderstanding and misapplying tools such as velocity.

    17. Many have been lamenting the misguided focus on delivery for several years now — glad you’re on the bandwagon.

    18. Raazi Konkader says:

      Using metrics as an end rather than a means will always result in a sub-optimal system.

      Velocity ought to raise questions than answer them.

    19. Hey Jim,

      Thanks as always for providing a real view of how things look in real life when you try things out! I am not sure I totally agree that having business-side people be solo product owners is a bad idea. As you say, the business is paying the bills, so they should get to call the shots. This is true even if they don’t totally understand the nuts and bolts of building a supple infrastructure. Even if they don’t, I think they need to be spoken to in terms of long and short-term ROI, since that’s where those quality and infrastructure issues are worth their time.

      I’m afraid that electing the tech lead as “co product owner” is a way of protecting business people from the consequences of their decisions, and inevitably when IT people reach out in this way, it comes back to bite us. No good deed goes unpunished. I vote they retain control, but we make quality arguments in terms they can understand.

      I ended up blogging on this — you might like it!

      Cheers, Elena

    20. At my last job, I can’t tell you how many times we were told by the product owner that we could never do fewer story points than say, X. Saying that we needed to do less than that this sprint to put some infrastructure in place would get shot down. Why? Because we had velocity on a big monitor at the front of the department and management didn’t want to have to answer awkward questions.

      That was fun.

    21. Olle Sundblad says:

      I agree with the problem of measuring velocity, almost all measuring ends in sub-optimization no matter what you measure (good leaders, which are rare, can minimize this).

      But think you have the wrong Product Owner (PO) if you have a customer or customer biased product owner. The PO should be a person who can balance the customer needs with the development team’s needs. In projects where I have had such a PO things work but when the PO is either development or customer biased things go wrong.

    22. This is a great post and it couldn’t have come at a better time for me. Right now, we are in a situation where management is asking us to plan what the team can accomplish in the 6 next months. Since velocity is easy to calculate and stories are estimated, we are projecting which stories we can commit to getting done in the next 6 months to have a plan to execute against. I argue that we have abandoned our agility by doing this, but the counterargument seems to be that we are using story points in the estimates, not hours, and therefore at it’s core this method is still agile.

      What are your thoughts?

      • Having a release plan out 6 months is a good idea–committing to enough stories to fill capacity isn’t. Must have stories should only fill 50-75% of the available capacity, the rest will get eaten up by adaptations.


    23. Prasantha says:

      A wonderful article. When an organization goes agile, I have the firm believe that all layers of management should be educated on Agile concepts first before any agile projects are undertaken. When they understand the concept, its very easy. As the Management always thinks about efficiency (which is fair), problem arises when they select the wrong mesurements for that.
      Thanks for the article.

    24. Yes, treating velocity as a production measure and trying to make it consistent across teams are misleading things – no question about that and thanks for pointing that!

      Yet, however, we just don’t be misled in the counterpart of mixing things up with the other need for the managers to work on ‘increasing the velocity’ for the sake of meeting project target (schedule) or fixing some issues in the process at hand. So, in some cases: related to team harmony, testing methods or tools, or any process-related issues – in those cases, the leader or manager would interfere to see what’s going wrong and try to fix it (not for the sake of productivity, but for the sake of increasing the ‘capacity’ itself)..


    25. Thomas C Ells says:

      Jim Highsmith’s blog here belongs under the heading of ‘the management of management’. All too often, mgmt is concerned with measuring, of getting involved and leading, when their best efforts are used in getting things out of the way, including themselves (witness the admissions of Sliger & Broderick, in “The Software PM’s Bridge to Agility”). This recognition is critically important, because it is about the “what” that will be produced (value points and cycle times), not the “who”. While “Agile” places proper early importance on the “who”, that is because they must give way to the “what”. In a recent academic software project, we were tasked with the inter-generational changeover to occur within an international art and collectibles auction house, which primarily involved an IT upgrade from zero, including hand journal accounting. So here, any level of response is possible and necessary, but not sufficient. “What” is the 21st Century “IT” response necessary and sufficient for an international art & collectibles auction house? Can they suffice with accounting, or should they look like the “Antiques Road Show” LIVE across several continents. If you are selling a Picasso, Monet, Manet, or Van Gogh, is your market the US, or Europe, or Japan, or is it all these places, and Saudi Arabia and Kuwait, and Qatar, and India, even China and Brunei? Then if this is your market, you better be able to address your market, and you better be able to consult with them on the “value proposition” and then sell them your “value”. This is more than an accounting IT upgrade, its an all out blitz upon your technology platform to have world-wide “LIVE” auctions. So, what is necessary and sufficient is nothing less than Porter’s 5 Forces, used in an integrative fashion with Agile to incise the product (using HOQ). Find your value points, set your cycle times. Great points in your blog.
      Thomas Ells, PE, MS Tax/Acc, MBA

    26. Dear Jim,
      I have been looking for a way to calibrate/estimate value points for some time now and can’t find a satisfactory way of doing it. There is something in the Evo method but it doesn’t get down to the detail of being able to put value points on all stories in your backlog
      like you can with Story Points. Can you point me in the right direction?

      • The secret is allocating relative value points, not trying to calculate them from the bottom up. There is a section on this topic in the 2nd edition of my Agile Project Management book.

    27. Steve Bement says:

      There is another way to keep maintaining the delivery engine, which I prefer, without the need for a technical member of a product owner team. The development team owns quality and owns the estimates already. Therefore, they can (and should) estimate the user stories appropriately, taking into account the effort needed to “refactor mercilessly”, address technical debt, and invest in things like continuous delivery. You can probably see in this approach the assumption that most all (maybe 95%) of this type of work can be done in connection with a user story.

      I have found that the other 5% can be explained to and negotiated with even a non-technical product owner. For example “let us do X or future stories will start taking 25% longer”.

      This goes along well with the concept of slack (an Agile practice that gets way too little attention) which, again, helps maintain the delivery engine without needing to create specific stories in the backlog to do so.

      See the following for more on slack:

    28. Steve Bement says:

      This is probably bad form, but I have to comment on my own comment! To clarify, I think that virtually all technical debt can be accomplished through following the practice of slack. Let’s say that covers 95% of it. For another 4%, I have found that necessary technical work can be accomplished through user stories that have value to the user. For example: “As a registered user I want the response time on the page to be less than 2 seconds, so that I don’t lose my train of thought and the flow of my work”. That may lead to tasks such as “tune the database”, but the team is given the “what” and they figure out the “how”.
      That leaves 1%, and it is those cases I was referring to in my previous comment where you might truly have a purely technical story. I like keeping that as a very rare thing, because otherwise the backlog starts getting loaded up with a lot of technical work with no visible user value.
      So for me, the order of things is something like (made up numbers):
      95%: Use slack to cover the vast majority of needed refactorings and other technical debt.
      4%: Write technical stories in terms of how it will benefit the user.
      1%: Have a purely technical story, that is negotiated with the product owner, in terms of the benefit it will provide to future velocity (or something like that).
      To me, allowing an entire category of technical stories into the backlog, as a matter of course, is just giving up on on the real value of user stories.

      But this is largely a side issue – I totally agree with the main points of this awesome article.

    29. Ritu Arora says:

      Awesome article. Agreed completely on mis-use of velocity metrics. If rightly used it is a good way to measure whether we as a team moving in right direction by optimizing the non-productive areas and reducing technical debts.

      Every metrics can be viewed in constructive or negative way. I see no harm in tracking velocity over a long run and then having rationale on rise and dip. This cannot be mapped to individual productivity but can definitely be mapped to leadership capability of taking right decisions and removing impediments which helped team.

      We built a framework and it is really helping. Velocity never comes down to team level. It is only tracked at leadership to ensure focus there.

    30. Actually, even using velocity as a capacity measure (except for planning the next sprint) misses a bit: it’s a capacity ESTIMATE, and a statistical one at that. Mike Cohn demonstrated the proper use of velocity ages ago, when he suggested using average and worst-case velocity over the past SEVERAL sprints to predict best and worst case delivered backlog over the next SEVERAL sprints (assuming, of course, that nothing gets added or removed from near the front of the backlog; it’s the rare manager who is willing to accept that something falls off the bottom when you add something to the top: “but you PROMISED feature X!”).

      For this reason, I’m much happier with cycle time as a metric, with the proviso that the team gets to slice up epics into manageable pieces at the intake. Capacity is what it is, and management can still demand overtime (as if violating sustainable pace will actually help), and Little’s Law allows management to actually shorten cycle time, IF they can agree on whose Work will NOT be In Progress. Chest thumping and demands aren’t even intimidating any more: demanding higher capacity is like defying gravity, it starts out fine, but hurts a lot, soon.

    Speak Your Mind