This is an excerpt from the recently released second edition of Exploring Scrum: The Fundamentals by Dan Rawsthorne and Doug Shimp. The authors of “Exploring Scrum” are both Certified Scrum Trainers for 3Back, a world-leader in Scrum development.
The reason we have Velocity, or similar metrics, is because we hope that by knowing how fast the Team has been producing Results we will be able to predict how fast it will produce Results in the future. That is, that by knowing the Team’s Velocity we will be able to predict the Team’s Capacity. The ability to do Release Planning (which we don’t discuss in this book) is predicated on having knowledge about the Team’s Capacity – how fast the Team can produce Results/Product. There are a number of Velocity-like metrics that people use for this, including:
- #StoryPoints/$100K – a different Velocity metric used by some, including Ken Schwaber1,
- $/StoryPoint – the average cost of a StoryPoint (in hours or $), and
- #Stories/Sprint – just counting the Stories Done in the Sprint; a very simple velocity metric introduced by Ron Jeffries, one of the originators of XP. He refers to it as Running Tested Features (RTF)2.
These are all nice metrics – and there are many others – but I’m only going to deal with the standard Velocity in this book. In any case – no matter which velocity-like metrics the Team uses – the goal is to be able to estimate effort or cost (or remaining effort or cost) based on the size of the work in the Backlog. The size of the work in the Backlog is estimated in StoryPoints, and the (velocity-like) metrics allow us to convert these StoryPoints to an estimate of Sprints remaining, cost remaining, or something equivalent.
Here is a question that is seldom asked about Velocity: ‘What properties should the Velocity metric have in order to be useful?’ I’m the kind of person that likes to go back to first principles, and I think this is a basic, important question – so I’m going to discuss it.
Well, first of all, if everything is in steady state – the Team, the Code, the Organization, and probably stuff I’m not thinking about yet – I would expect Velocity to be essentially constant. This property of Velocity is what allows predictions into the future, and gives some confidence in any Release Planning that we might do.
What would we expect if things are not in steady state mode? What if the Team is getting better (or worse)? What if Technical Debt is changing? What if the Organization is undergoing turmoil and interfering with the Team? What should we expect from the Velocity metric then? I don’t know about you, but this is what I expect:
- If the Team is getting better (or worse) I would expect the Velocity to be increasing (or decreasing). I’d like for my Team to get credit for improvement, and the Velocity is where the improvement is made visible. As an ex-runner I know that getting better means that I’m getting faster; that is, my Velocity is increasing. I also know that if I’m getting slower, my coach is going to have a conversation with me to try to figure out what is going on…
- If the Organization started messing with my Team more than usual I would expect the Velocity to go down. Perhaps I (the Team’s ScrumMaster) could use this decreasing Velocity to influence the Organization to ‘lighten up’ a bit. On the other hand, if the Organization becomes more empowering and nurturing towards my Team, I would expect the Velocity to go up, and I could use it to prove to the Organization that ‘being nice’ works.
- If my Team is creating buggy code or otherwise adding to the Technical Debt I would expect the Velocity to go down – Technical Debt makes the code hard to work with and increases the cost of change, so the speed of producing Results should decrease. In fact, since Technical Debt is invisible from the outside, a change in Velocity might be the only externally-visible manifestation of the change in Technical Debt – either positive or negative.
In other words, I want Velocity to be essentially constant if things are unchanging, but if things are changing – if the situation is not in steady state – I expect that Velocity will change to reflect the changes. Furthermore, I need the Velocity to change if the factors that cause that change are invisible to my Team’s Stakeholders. This is because the Velocity metric is visible, and by seeing a change in Velocity my Team’s Stakeholders can infer that they need to ask questions about things that are normally invisible to them. Scrum is about conversations, not metrics, and I want whatever metrics I use to cause conversations. That is, I not only want metrics to tell me some truth, but I want them to be indicators of things that need to be discussed and that Stakeholders should ask questions about.
Find out even more about team velocity, size, and Scrum development by checking out the Exploring Scrum website or purchasing Exploring Scrum: The Fundamentals on Amazon. If you’re interested in becoming a Certified ScrumMaster or Certified Scrum Product Owner, 3Back offers classes all over the country. Stay agile!
[1] Personal communication. Also found in Ken’s current (as of 2010) Scrum Training Materials.
[2] https://xprogramming.com/articles/jatrtsmetric/