During last webinar, we have got a lot of questions regarding metrics and the Scrum Team.
In this post I will try to address a few of them.
Can you give examples of team metrics you found useful?
Well, for me, the important thing in using metrics is understanding the context and answering 4 key questions:
What do we want to measure?
Why are we measuring it?/What for?
How are we measuring it?
Let me give you an example. Let’s say there is a problem within your Scrum Team in focusing on their work throughout the sprint. You observe that members are constantly interrupted with questions, meetings, phone calls, chats, etc. Your hypothesis could be: “We need to reduce those interruptions to help the team perform more efficiently.” But before you take any action, let’s start with measuring.
1. What do we want to measure?
We want to measure how many times a day each of our team members is interrupted by a non-critical issue. For that, we would need to establish what is a “non-critical task.” For the team I work with, “non-critical issues” were anything that could wait at least a day without causing impediments to others within the organization.
2. Why are we measuring it?
To validate our hypothesis and help our Scrum Team work more efficiently.
3. How are we measuring it?
In my team’s case, every time someone would approach us in our open space (these were still the times we were sitting in offices;) and interrupt our concentration work, we would mark a quick line on our whiteboard. By the end of the Sprint, we would count all of those lines and see what is the scale of interruption.
4. What’s next?
Now, we showed our results during the Sprint Review and discussed them during retrospective. If we are spending over 70% of our time, how are we [as a team] supposed to focus on product delivery? This prompts us to re-evaluate our presence at some of the meetings and adapt our way of working
Apart from velocity, what other metrics can be used that will bring value to the Scrum Team?
Measuring the quality of the code can help teams identify areas for improvement and prevent technical debt from accumulating. Some metrics for code include code coverage, code complexity, and code review feedback.
2. Cycle Time.
This can be defined as how much time do we need to move a task from in progress to done.
3. Customer Satisfaction (NPS)or any other metric to make sure we are building the right thing product-wise.
4. Team Happiness
Keeping team members engaged is important for making sure we have the right amount of workload in our Product development and can help prevent potential burnout and spot places for improvement.
5. Product Owner Surprise Factor
This is one of my personal favorites. I measured how many times a Product Owner was surprised at a Sprint review with stakeholder feedback. Or with what the Developers build. It could show us how much our Product Owner was actually engaged with the development process.
Whatever metric you choose, keep in mind that once you establish what you want to measure, make sure it is followed by what next?
Whatever metric you choose it’s important to keep them transparent, inspect and adapt as to make conscious decisions regarding our Product.