What is Scrum Team Velocity?
This is a tricky one, and you need to be answering it in the context of the organization you are interviewing with and its complementary practices.
Let’s start with the basics. Velocity is mentioned quite a few times in connection with Scrum in various contexts. First thing you might hear is that the velocity is a measure of the team’s ability to deliver value to the customer. That’s quite an okay definition you might give to your interviewer. Just be ready for an onslaught of questions it might bring, such as, “What do we measure”, “How do we measure it”, “Why do we measure it”.
Velocity is recognized by Scrum.org as a complementary practice. This means, that Scrum framework does not have a prescription for a Scrum Team as to how to measure its ability to deliver value. Remember that Scrum is a framework, which can work really well with a variety of practices that fit teams needs, desires, and abilities. And velocity is one of such practices.
Scrum Glossary, maintained by Scrum.org, defines velocity as “an optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.”
This is a mouthful. Let’s dig in and understand what it is all about.
Remember the primary goal of any Scrum Team; it is to deliver customer value in a form of a Done Increment at least at the end of every Sprint. Scrum Team converts selected Product Backlog Items (PBIs) to a valuable Done Increment, which Product Owner could release at her discretion to the customer.
The way we measure the amount of Product Backlog turned into a Done increment is another complementary practice. Many teams choose to use story points. There is a whole body of knowledge that describes the definition, use, and pitfalls of using story points for estimating and tracking the work. One important thing to remember of those, is that story points is an abstraction; it is a way the team is thinking of a unit of its work. It is in no way a measure of team’s performance and therefore should not be used (or misused as it happens quite often) to measure such.
There are other complementary practices to measure the amount of work the team performs. Some teams might track hours (the shortcomings of this approach are a few, but outside of the scope for this discussion). Some teams, after rightsizing their PBIs, might track the number of PBIs converted to the Done Increment. That is the preferred way to track the work for the teams practicing the Professional Scrum with Kanban (PSK).
Whichever way the team chooses, remember, it’s their own unique way, designed to provide the team with its own measure of its progress and in no way should be applied to wrong use, such as being a measure of comparing performance across different Scrum Teams.
In the words of Scrum Glossary, velocity is the metric “for the team, by the team”, and no one else.
If the team uses Velocity as one of its metrics, what is it good for you might ask. I would say it is one thing, and the only thing – an input to the Scrum Team Sprint Planning. Remember, that inputs to the Sprint Planning, according to the Scrum Guide, are “the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.”
That last thing – past performance of the Development Team - might just as well be its Velocity, but not mandatorily or exclusively. It can be any other metric the Scrum Team decides to adopt as a measure of its past performance. Just to reiterate, Scrum is a framework that works very well with other complementary practices that various teams decide to use and adopt.
What about “twice the work in half the time?” If you get this follow up question in an interview, this is a good time to thank your interviewer for his / her time and leave. Just kidding. Don’t do it. Remember, one of your responsibility as a Scrum Master is to teach and coach Development Team and the organization in its Scrum adoption.
In this case you might suggest, that the message of Jeff Sutherland’s book is often misconstrued and misunderstood or taken too literally. Scrum is not about making your teams go faster, 4 times, or whatever other multiplicator the organization has in mind. Scrum, as an empirical process control instantiation, will ensure focus on he value delivery through continuous inspection and adaptation, while promoting transparency into its artifacts and the process.
As such, the velocity is a completely inappropriate measure of the value delivered. For more conversation on the metrics the organization would want to use to measure the value delivered, I invite you to explore the Evidence Based Management Guide.
This is all for this week's interview question. If you are looking to improve your Scrum Mastery Skills, consider attending my Professional Scrum Master II course in Houston on April 25-26.