Agile (Scrum included) has a very complicated relationship with metrics. One the one hand, Scrum is an empirical approach, meaning that you make informed decisions based on your observations. Often times, these observations are best represented by metrics. On the other hand, focusing on the wrong metrics can sidetrack a team that is trying to do Scrum, especially in large organizations where Agile has been adopted for all the wrong reasons.
To make sure this doesn’t happen to you, today we will be looking at some useful Scrum metrics that will actually help you get the most out of the framework without bogging your team down in unnecessary numbers and charts.
The success rate of sprint goals
The Sprint Goal is an integral part of the Scrum framework, defined during Sprint Planning. By definition, it's designed to answer three simple questions: "Why is the team carrying out the Sprint?", "How does the team reach the Sprint Goal?" and "What metrics can tell you that the goal has been met?" A Sprint Goal can be anything from developing a feature to testing a requirement.
The fact of the matter is that when you clearly define Sprint Goals and then measure just how many sprints actually meet the goal, you can gain insight into the Scrum Team's work and their overall efficiency. That doesn't just include how many user stories are completed but also how frequently business objectives are met as well.
Agile practices that are often added to the Scrum framework require Scrum teams (especially mature ones) to rely on activities, such as continuous integration and test-driven development (TDD), in order to ensure maximum value and quality of products being developed.
Defect ratio is a metric that indicates just how many bugs users have experienced during the development process. As you may already know, nothing can be 100% bug-free but Agile emphasizes that the number of bugs within software gets reduced to a minimum. A Scrum team tests each story to avoid defect but it sometimes happens that a few defects manage to escape.
Another one of the Scrum metrics that can complement defect ratio is defect density. This metric indicates defects per software size or per lines of code. In fast-moving projects, this metric can indicate the number of defects and whether they are increasing, decreasing or remaining the same.
This metric can be valuable in Scrum projects but it should only be used in comparison to other factors but not as a goal. Team velocity indicates how many uses stories can a team complete each sprint, on average. It's used to estimate the amount of work the team will be able to accomplish in future sprints.
Under no circumstances should anyone try to force increased velocity because it can have a major negative impact on the team's progress and general wellbeing.
Sprint burndown metric is portrayed through a Scrum burndown chart. It's a visual representation of progress for each individual sprint. As an example, it can show how many hours are left to complete user stories for the day that were previously planned for. In other words, a Sprint burndown can show the team's progress and help determine if the team is on schedule to successfully complete the sprint on time or not.
Time to market
This Scrum metric portrays how much time is needed for a project to start delivering value to customers. Various companies measure value in different ways. As an example, some companies measure value when a product starts generating income. In that case, the value is the money a product can make. There are a few factors to consider when measuring time to market. Here's an example.
- You can measure the time from the projects beginning to the time it starts delivering value as the time to market.
- Normally, Scrum teams deliver working bits of a product after each sprint. In that case, the time to market is the duration of the sprint.
- Some Scrum teams deliver working bits of a product after a few sprints and release product features in groups. In that case, the time to market is measured from the start of the feature development to the next release.
Return on investment (ROI)
In Scrum projects, ROI can be calculated by assessing the revenue generated by a developed product vs. the costs of each sprint required to develop a product. The fact of the matter is that the Scrum framework can help products generate revenue much faster than the traditional methods (it does not guarantee this). The main reason is that Scrum projects deliver working bits of software early on. With each new sprint, the development team releases new product features which can be viewed as revenue growth opportunities.
This Scrum metric measures whether it's worthwhile to continue a project or not. When the costs of development exceed the value, it's time for the project to end. In such cases, the team will be redeployed to other still profitable projects.
In order to calculate capital redeployment, you must measure the value of the remaining items in the backlog (V), calculate the cost of developing those items (AC) and compare it to the opportunity cost of an alternative work a team could possibly be doing (OC). Therefore, if V < AC + OC, the project should end and the team should be redeployed elsewhere.
It is crucial to remember one thing about Scrum metrics we have covered today - their purpose is to inform teams about how they are doing and to help them honestly and transparently analyze their workflow and find ways in which they can improve.