Crucial Agile Project Management Metrics and KPIs: NIX Approach

Project management key agile metrics and project management key performance indicators (KPIs) are essential for quickly tracking the progress of a project. They allow you to quickly monitor development, measure performance, and set goals—but how do you know what exactly is worth measuring for each project?

Below we will highlight the most common project management metrics used in various aspects of software development. It is important to note that not everything listed below is necessary for your project—you can pick those that are perfectly suited to track the development of your particular project, identifying your goals and success factors. 

What Project Management Metrics & KPIs are

Project management metrics show a project manager (PM) how different areas are performing and those which may need improving and if they are quantifiable or countable. As we said above, these metrics are important for a variety of reasons, namely software performance measurement, work item planning, productivity management, etc.

Within a project, there are a large number of metrics that overlap with each other and are linked within the management function. The purpose of monitoring and analyzing agile software development metrics is defining the current product status, improving it, and, eventually, providing quality after the software development project is complete.

Project Management KPI Categories

Starting from the basics, let’s look at 4 categories of management functions that are worth considering for your project management KPIs—time, budget, effectiveness, and quality.

Time KPIs

Please note below we have provided all possible agile metrics for your complete understanding. You won’t need all of them, but hopefully, they will help you understand the best ways to manage and track your projects.

1. Cycle time: The time to complete a specific task or activity, important for repetitive tasks in a project. 
2. Lead time: The time from the moment a request is received until the task is completed. This metric is important for finding bottlenecks throughout the process. 
3. Resource capacity: The size of the team working on the project multiplied by the percentage of time they have to work on the project. This metric can help with the proper allocation of resources and thus help in establishing an accurate timeline for project completion. 
4. Schedule performance index: How much work is done relative to what was planned. 
5. On-time completion percentage: Whether a task is completed by a certain deadline.
6. Time spent: Time spent by each team member or all together. This depends on how much time you want to track.
7. Scheduled hours vs. time spent: If there is a striking difference in these rates, it is worth reconsidering the resource allocation or budget, since this can end up affecting the schedule.

Budget KPIs

8. Actual cost (AC): How much money was spent at a certain point in time. 
9. Earned value (EV): The budget spent compared to the work done.
10. Cost performance index (CPI): A ratio comparing the planned cost of work to the amount spent so far. If the coefficient of this ratio is more than 1, you are moving within the budget; if lower, you went over budget.

Formula: CPI = EV/AC; CPI = 1

11. Cost variance: This shows the discrepancy between the planned budget and what has already been spent.
12. Planned cost: The planned cost of what still needs to be done. Compare this metric to actual cost and adjust the budget if necessary.
13. Planned value: This shows how much of the budget will be spent at a certain point in time. Used in earned value management.

Effectiveness KPIs

14. Number of project milestones completed and signed on time: Indicator of whether the project parts are done on time. 
15. Number of change requests: The number of clients‘ requested tasks to make changes to the defined scope of work. 

Quality KPIs

16. Number of errors: The frequency of cases where you have to redo or rework something during the project, which also affects the revision of deadlines and budgets.

Regardless of which project management methodology you choose, you can use the above-mentioned project management KPIs. But of course, none of this matters if the data are not collected and analyzed. The problem may arise from the fact that development teams may believe that actually getting the work done is more important than measuring progress. In this case, it’s better to have an experienced PM to handle issues.

Agile Metrics to Measure Project Progress & Optimize Delivery

The following agile project management metrics can help measure the work done and value delivered to customers.

Velocity

This displays the amount of work accomplished in a sprint. This helps estimate what part of work the team can perform in future sprints. A more accurate match between commitments and costs is seen when the speed is tracked over a long period of time.

This indicator is individual and different for each team. Trying to artificially increase speed can undermine trust and decrease transparency between teams and management.

Speed also determines the team’s ability to work on backlogs. This may change over time and should be monitored to ensure consistent performance. Development problems and the need for change in the workflow will be clearly traced if there is a decrease in the predictability of the flow.

NIX Tips and Examples 

• Use the focus factor
  If the team has external/internal triggers, it’s best to use the focus factor in your planning. For example, if you plan for the team to close 40 SP per sprint, but several people have left to work remotely and communication processes will be rearranged along the way, you can assume that the focus factor is 0.8, and therefore the team will be able to close 40*0.8 = 32 SP
• Changes in the sprint backlog on a regular basis
  Try to avoid regular changes of the sprint backlog, as people will be unfocused, they will need to immerse themselves in the task, evaluate, understand dependencies, etc. This leads to a systematic decrease in velocity.
• Eliminate inconsistency after a triplet of sprints
  If you are tracking inconsistent speed for an extended period of time, try to assess external and internal factors that may interfere with a clear assessment.
• Recalculate speed when there are changes in the team
  When someone leaves a project or when someone is added to the team, recalculate the velocity or resume the calculation entirely.
• Don’t compare performance between Scrum teams
  One team’s velocity cannot always be compared to another team’s velocity, because each team has its own way of evaluating and understanding the complexity of tasks, and maybe working on different kinds of tasks. Other than demotivating a team that closes with less SP, you get nothing.
• Three sprints are enough to make a prediction about future performance. 

Sprint Burndown Chart

Displays how much work is left to manage before the end of the sprint. This criterion is valuable because it does not simply list the items completed, but shows the progress toward the goal. Also, the sprint burndown chart is indispensable in identifying planning errors that were made at the beginning of the sprint.

The sprint burndown chart is a traditional representation of a sprint’s progress. It gives the remaining hours to complete the tasks scheduled for the current sprint for each day during the sprint. This graph provides an instant view of whether the team is on schedule to complete the sprint.

NIX Tips and Examples

• Correct task decomposition and dependency planning
  If tasks are not decomposed correctly, a situation can arise where one part is done and the other part of the task is stuck halfway through the sprint because the team is busy with another task. Because of this, a situation may arise in which the task closure is uneven and the graph on the burndown chart will fluctuate a lot. For example, there was no progress until the middle of the sprint and the team was behind, and then it may have collapsed dramatically downward.
• Task workflow should be consistent
  If there are any hidden stages where the task might get stuck (e.g. code review), this will be clearly visible on the burndown chart as the task is not deliberated. It is necessary to set internal rules and manage bottlenecks. For example, a task should not be in code review for longer than one business day.
• Take unplanned tasks into account
  A summary chart is helpful for identifying the size of untracked tasks. If the scale of work is getting larger, not smaller, it may be a signal that there are many unplanned or underestimated tasks in the project that need to be eliminated.

Agile Metrics to Assesses Process Efficiency

Project management performance metrics are those that interlink with process efficiency. Let’s check the following metrics:

Cycle Time

A measure of the time that has elapsed from the time an item (story, task, error, etc.) started until it is ready for delivery. The cycle time indicates how many calendar days it takes to complete a task.

Predictable results are shown by teams with constant cycle time. Moreover, teams with short cycle times have high throughput. By measuring cycle times, you can increase the flexibility of your processes. For example, in the case of changes, you can know the results instantly. As a result, team members can make necessary adjustments. Overall, short and consistent cycle times are a goal that should be achieved in every sprint.

NIX Tips

Cycle time can be used not only to measure what the development team does—using the Kanban method, we break down all the work into stages and measure cycle time for stages such as:

• Idea development and requirements writing
• UX work
• Design
• Development
• Testing

Flow Efficiency

This gives an indication of the distribution between actual work and waiting periods. This metric, for some reason, is often overlooked.

It is used to understand what is your process prevents you from pushing a task from start to release through the entire workflow.

For example, we can’t give tasks to the testing environment because the deployment is very complex and it needs a lot of time, so it doesn’t happen very often. Looking at flow efficiency, it’s worth thinking about auto-deployment every day to increase efficiency.

Cumulative Flow Chart (CFC)

Provides consistency of workflow in the team. CFC measures the state of work in progress. With this in mind, you can take steps to speed up the workflow.

This criterion is described by a diagram that displays the number of various types of tasks at each stage of the project, where the x-axis represents dates, and the y-axis represents the number of points on the graph. The diagram shows obvious bottlenecks. You can analyze how the bottlenecks formed first, and the team can then take steps to eliminate them and make improvements.

The point is to visualize how tasks are divided up at different stages of the project. The bar on the graph with “completed” tasks should be constantly increasing. An increase in backlog always highlights unresolved tasks that are either out of date or too low a priority.

Also, this graph helps to understand how balanced the team is. For example, if the team is lacking QAs, the “Ready for testing” bar will steadily increase—this is an obvious bottleneck. Or, if the team doesn’t have enough backend developers, we’ll see that front-end tasks get blocked due to waiting for tasks from the backend side—bottleneck again.

Agile Metrics to Ensure Code Quality

Software quality metrics provide a better understanding of how reliable and safe your code can be. Some important ones among agile software development metrics are those below.

Code Coverage

This measures the percentage of code covered by unit tests. This metric represents the percentage of code coverage in raw form and gives a worthy progress perspective, but it does not cover other types of testing. Thus, high code coverage rates do not necessarily mean high quality.

Code Churn

This visualizes the trends and variations occurring with the code base, both as a whole in progress and over time until release. Code churn measures how many lines of code have been added, removed, or changed.

While this metric may seem a little rudimentary, it provides a measure of code stability at different stages of development. You should expect the least stability in the early stages of development, and the most stability just before release, with the least churn. If your code is very unstable and the release date is approaching, sound the alarm.

McCabe’s Cyclomatic Complexity

This measures the complexity of the code and is often seen as a magic number to measure the complexity of a program. Less cyclomatic complexity = better code.

It does not cover all kinds of program complexity, but it allows you to clearly define functions with more loops, select statements, and switch/cases.

Formula: CYC = E – N + 2P

What Makes Good KPIs for Software Projects? 

Choosing project management KPIs and agile metrics to monitor and measure is only the first step. Next, you need to define the KPIs so that they are clear and focused. Your KPIs should be agreed upon by all parties involved before the project begins and then measured and monitored as a decision-making tool during the project. Let’s focus on what can enforce your KPIs.

Make the Connection Between Metrics and Goals

Often sets of software metrics are reported to software development teams as goals. That is, the focus is on: reducing the number of lines of code, reducing the number of bugs reported, etc. And as a result, we get the better utility of the software and a better user experience.

Keep the Focus on Tendencies, not Numbers

Software metrics are very seductive to management because complex processes are presented as simple numbers, and those numbers are easy to compare to other numbers, so when the software metric target is reached, it’s easy to declare success. Failure to reach that number lets software development teams know that they still need to work toward that goal.

These simple goals don’t provide as much information about how software metrics are changing, because any single data point is not as meaningful as the trend of which it is a part. Analyzing why a trend line is moving in a certain direction or at what rate it is moving will tell you more about the process, and trends will also show what effect any change in the process has on progress.

If the goal is not achieved, it can, unfortunately, be perceived as a failure, but a trend line that shows progress toward a goal provides encouragement and insight on how to reach that goal.

Set Shorter Measurement Periods

By breaking up the measurement periods into smaller time slots, the software team can check the software metrics—and the trend line—to determine how well they are progressing.

Yes, it’s intermittent, but giving software teams more time to analyze progress and change tactics if something isn’t working is very productive. Shorter measurement periods provide more data points that can be useful in meeting goals, not just data about software metrics.

If you are looking for a strong management team or have any questions on your next project’s agile metrics, contact NIX experts.

Conclusion

Make no mistake that the more software metrics you use, the better the result of the project. There is a risk that numerous ratings, scores, and agile metrics will simply overwhelm you with numbers.

It is worth carefully selecting a few of the most appropriate project management metrics—depending on the goals of the project—and stick to them. To find out exactly what you should measure in your project and what you shouldn’t waste your resources on, contact our experts.