Metrics can easily get a bad rap.
And I understand why. Sometimes, in our bid to prove we’re adding value, we hastily start measuring things - anything - without any real thought on how they can help.
 |
| Unsplash Photo by |
For me, metrics are not about having something to report on. It’s about getting a better understanding of how we’re working. They should help inform some of the deeper conversations that we need to have, as we embed continuous improvement as part of the culture.
I must add too, that like everything else, the metrics that a team uses will evolve over time. It’s important to look at where we are, identifying what’s the next best step to take and in figuring that out, selecting the correct metric that can help us unearth the opportunities.
For software development teams, especially newly formed teams, I will share a few metrics that I recommend starting with.
This blog post will focus on the first one - VELOCITY.
Full disclaimer!
1 Velocity
Full disclaimer!
There has been a lot of talk about how negative it can be to use velocity as a performance metric. I completely get it. It’s one of those metrics that can be easily misused. So let’s lay out some context before we start diving into why look at velocity.
As an Agile team, the aim is to deliver incremental value, early and often. That means, we need to be getting work done and into the hands of our customers.
“Working software over comprehensive documentation”
As an Agile team, the aim is to deliver incremental value, early and often. That means, we need to be getting work done and into the hands of our customers.
This is where velocity is useful - in helping to forecast or estimate how much work can be reasonably done, based on past performance.
But as useful as it can be, it can be as easily misused. Here are just a few of the ways:
But as useful as it can be, it can be as easily misused. Here are just a few of the ways:
✖ As a comparative tool across teams.
Teams differ. No two teams will work the same, just like no 2 humans will do anything in the exact same way.
Even if both teams are considering the same factors when looking at a story, there are nuances and differences in how they may approach the work.
Therefore, we should never, ever, under absolutely no circumstance, compare the velocity across teams.
Velocity will fluctuate sprint over sprint. That’s a reality.
 |
| Unsplash Photo by |
✖ As an absolute forecasting tool
Velocity will fluctuate sprint over sprint. That’s a reality.
When working in an Agile manner, we start with what we know and as we proceed, we uncover and learn new things. Sometimes new work emerges. And that also means, sometimes the initial plan has to be adjusted and adapted, based on that new information, to allow for discovery or investigations, which may result in a new plan or approach being required.
To expect a team’s velocity to be fixed and remain unchanged, may not be the most reasonable (or practical) expectation. So while the velocity can help us to forecast, based on the information at present, a team should never be penalized or chided if those forecasts change. They are best guesses, not an exact science.
How can velocity be helpful?
➤ As a reference tool in any planning exercise
It can help keep the team grounded - or better yet - keep their plans realistic.
Sometimes our teams are overly optimistic about what can be accomplished in a given period. By looking at what we were able to accomplish in past periods, we can eyeball if we seem to be taking on less or more work.
In either case, a conversation can be prompted by asking questions such as: what is different about the work that we are doing now?
 |
| Unsplash Photo by |
➤ To prompt a deeper look into why work was not completed
Velocity charts also indicate the amount of work not done.
Depending on the type of tool being used, we may also be able to drill down to see exactly which piece of work was not completed. Having this information makes it easier to dissect, as a team, the factors that impacted us completing that piece.
Where there were factors external to the team, there is an opportunity for the Scrum Master to bring the issue to the attention of the responsible stakeholders.
Where the factors were internal to the team and within our control, the conversation shifts to questions like - what can we do to prevent a recurrence? What do we need to do differently next time?
In the next post in this series, we'll examine 'CYCLE TIME'.
0 comments: