From the perspective of Scrum, metrics and KPI evaluations are a few of the last frontiers in the process for continuous improvement. In this article, Lucas Napoli shares some metrics and KPIs that Agile software development teams should be aware of.
Author: Lucas Napoli, Hexacta, https://www.hexacta.com/
From the methodology perspective, metric measures and KPI (Key Performance Indicators) evaluations are a few of the last frontiers in the process for continuous improvement. The values and charts that result from these practices help the client to make important decisions about the project, but also help the development team demonstrate the status of the situation.
A couple of weeks before, we discussed those KPIs that are important for clients to take into account. With the aim of going a bit further and showing other important metrics within software projects, in this opportunity, I decided to focus on the KPIs the development industry should be aware of. Clients can also keep these in mind to see in detail if the outsourcing company is measuring the development properly.
All participants in a project should be committed to these practices, and everyone needs to know the importance of reporting consumed hours, estimating effort, and other tasks that are not specifically related to software. In this article, we are going to enforce this idea, explaining the most commonly used metrics in Agile software development and their purpose.
What are metrics and KPIs in software development
To start with, it is important to clarify that one of the most common mistakes is to use metrics and KPIs as synonyms or interchangeable concepts. Let’s focus on the differences.
Metrics are quantitative measures used to track, demonstrate, and compare the performance of a software development team. These values describe different aspects of the ongoing project like reliability, performance, security, maintainability, and principally, quality. For its part, the KPIs are also measurable values, but they track the achievement of the business objectives.
In a few words, while metrics concentrate on the status of the project and show momentum, the KPIs trace how the achievement of goals goes and show the impact in the outcomes.
These two concepts are extremely related, because both are measurements, but the key is in the impact. If a metric becomes important for the business to know about the added value of a project or product, then it can become a KPI, and vice versa. When a KPI does not describe any impact, it can return to the metrics list.
So now, let’s focus on the development team and how each member needs to be involved in both the metrics and the KPIs. Here are some common and useful Agile software development metrics.
1. Sprint Burndown chart
The Scrum methodology divides the work in timeboxed periods (Sprints) in which the Scrum team commits to resolve or deliver certain amounts of tasks fixed at the Sprint Planning. The Burndown chart tracks how many tasks or hours are left to complete the Sprint commitment and compare it to the ideal flow.
To read the Scrum Sprint Burndown Chart, simply consider values above the ideal line as deviations, because the team is somehow delayed or blocked at a certain time. Values below the ideal mark show overestimated work, leading to leisure time in the team that can be adjusted in the next iteration, committing to more work.
From the project management perspective, this chart is useful to track the Scrum team’s performance, but it does not consider any benefit to the team itself.
The key to see the real added value of the metric in the team is to check the historic picture. We can compare different Sprint charts to understand the dynamics and be able to identify high traffic dates and to notice blockers or bottlenecks. It is also important to mark in the timeline if a particular change was made in the team and check the impact in the Burndown chart.
2. Velocity
This metric tracks or determines how much work the team can commit to doing Sprint after the Sprint. It is a simple metric to calculate, but it needs the whole team to be involved.
Velocity lays directly into estimations, and estimations strongly depend on the team’s communication in the different ceremonies.
Velocity tracks the amount of work a team achieved in the last Sprint, and it is just a sum of all the effort in points or hours. It helps to plan the next Sprint appropriately and to do so, there are some keys to consider:
- Effort. No matter if it is calculated in hours or points, it is a value that needs to consider the dimension of the work and the knowledge.
- Bugs can be part of the planned work. It is better to have a list of planned bugs for the next release, so it is possible to add them as part of the effort. In addition, unplanned bugs should be considered at the Sprint planning as part of the development for a work item like coding, unit testing, and functional testing, reserving some space for unexpected events.
- Handle re-estimation of the work vs. new work. While some Agile gurus are not big fans of re-estimating the work in the middle of the Sprint if an item or Story deviates from the estimated effort, there is one important thing to have in mind in these cases: Handle the change. You do that by creating new work items, estimated in the middle of the Sprint or changing the original value (note that this can affect the velocity).
- All developers should estimate. It doesn’t matter if they do the work or not. Thanks to this, fluent communication and healthy discussions are promoted. If the estimation is made at the Sprint planning, a moderator can conduct the conversation.
- Velocity is not only a team metric. Because the discriminated value by developers can give information about the person’s performance, it is always important to keep the team notified if some blocker or special situation affects the individual velocity.
- Everything will make sense down the road. Velocity is a metric that achieves its purpose once the procedure is mature. Estimations will be more conscious, and the committed value for a Sprint will have fewer deviations.
3. Lead and Cycle Time
These metrics are two facets of the same lifecycle: start a work, finish a work.
Lead Time considers the average time between the moment a work item is added to the Sprint backlog and the time it closes. It expresses the whole team dynamic because it involves business analysis tasks, development, design, testing, and UAT hours. The key to success with this metric is having enough backlog to fill the entire Sprint. In addition, it will be important to have single purpose work items (avoid having Stories or bugs with 8+ Story Points).
Cycle Time tracks the average time between when a work item is activated (the work started) and it is closed. It also depends on fine-grained Stories to have a meaningful value and to express the actual development time.
Like Velocity, Lead and Cycle time metrics need the commitment from the whole team to track the most accurate hours of consumption, so it is important to breakdown each work item in subtasks to then track the hours.
Finally, there are two concepts to debate on with these metrics: when a work item is activated and when a work item is considered closed. These two moments in the work item’s life can have many definitions.
One says that a work item is activated when it is added to the backlog. Others state that this happens when the developer accepts the assignment or when the item is marked as active.
A work item can be considered closed when the development is done and ready for testing, when the item passes QA with no pending bugs, or when the Story passes the UAT. It is important to differentiate those definitions to avoid misunderstandings and to know how to read the values after calculating the metrics.
Last words about Agile software development metrics
To wrap up the lines above, it is necessary to enforce the need for all the team to understand the metrics, learn how these values express their daily work over time, and how we can be part of something bigger.
Metrics and KPIs in Agile software development projects are helpful from all perspectives, but not without context. These values might seem cold (with the purpose of showing performance deviations), but they can also demonstrate the dynamic within the team and the ups and downs of the process. They can also be a thermometer of how good or bad decisions affect the group.
About the author
Lucas Napoli, is a Project Manager at Hexacta for the development of enterprise technology applications and supporting the entire development life cycle using Agile Scrum. This article was originally published on https://www.hexacta.com/agile-software-development-metrics-for-teams/ and is reproduced with permission from Hexacta.