Depending on the level of maturity a software development team, the velocity stabilizes after a few sprints. The team and the Scrum Master(s) are working to increase the velocity. But how do I measure that? And while we are talking about speed – is the car actually driving in the right direction?
Note: This Blog entry was inspired by Jessica Kerr on GOTO Conference Copenhagen in October 2017.
Intro
Agile methods are now well established. Relative estimation methods such as story points belong to the standard repertoire of software developers, product owners and testers.
In this post, I show you how much important information can be obtained from these simple metrics.
Step 1 – How fast is the car driving?
Story points (SP) are a relative measure for the complexity of a task. For example, a user story estimated at 8 SP is about 4 times as complex as a story estimated to have 2 SP. A Scrum team, we call it Fantastic Four, estimates several stories and plans with a sprint duration of 2 weeks.
Using a formula from physics class in school, this becomes an important metric: speed, defined as the distance over time.
The speed or “Velocity” now shows us the maturity level of a Scrum team: is the team overcommitting? Is the velocity stable between sprints?
In the case of our Fantastic Four, 3 user stories of 8 SP each add up to 24 SP in total, corresponding to a velocity of 24 over a 2-week sprint.
Story points are a relative metric and are only valid in the context of a specific team. Velocity is never used to compare two different teams directly (“A is faster than B”). This is counterproductive and should definitely be avoided.
You can use pencil and paper to calculate the velocity, but of course also Excel or tools like Atlassian Jira. Product owners who know the velocity (i.e. the capacity) of different teams can now use this information as part of the release planning.
Step 2-Accelerate
Our Fantastic Four have a velocity that has been stable for several sprints now, 24, 24, 24, this is called the cadence. In this example the acceleration would be constant at “0” because the velocity does not change. Again, remember physics class: acceleration is the change in speed in relation to the change in time (= “first derivation of speed”).
Stability is great, one would think – but for the team’s Scrum Master, this is a signal to give new impulses. Her job is to remove any impediments from the team’s path so the Fantastic Four’s car can accelerate – to stay in this picture. Acceleration becomes the ideal metric for Scrum Masters.
It is important to note that velocity and acceleration of a team are not an end in themselves – they are basically just a symptom. If you demand ever higher and higher velocities from your crew, then depending on the team you either receive inflationary effort estimates (what used to be 3 SP yesterday are 5 SP today) or, and that would be almost more dramatic, the team accrues technical debt.
In this case, the car would sooner or later come to a grinding halt with an engine failure.
Step 3 – Are we there yet?
I also use a concept from physics for the next step. Fun fact: speed is not just a number, but a vector (which is a fancy way to say that it has a direction).
In relation to our Fantastic Four, this means that higher, faster, further only makes sense if the direction is right. Are we developing the right product?
Concepts such as user personas, the product vision or an MVP are quite handy here, as they reflect the customer’s perspective and elicit feedback.
TL;DR
This blog post was a short excursion into the world of agile methods – combined with a mini-physics class. From a simple effort estimation, I gradually developed tools for the entire team, the product owner and the Scrum Master. Just remember that it’s about quality first and foremost. Make sure you’re building the right product!