Agile software development continues its success story in the developer scene and is now considered the most widely used development method: the Agile Development Adoption and Best Practices Report shows that more than 55% of all IT companies now work with agile methods.
Despite the high flexibility and adaptability of agile methods and their quick reaction to change, workflows can and must be measured and controlled centrally. Agile KPIs (Key Performance Indicators) provide information about potential improvements in the strategic planning, evaluation and implementation of agile projects.
Traditional quality management systems usually focus on meeting requirements within a time and monetary framework. In agile software development, however, customers and development teams have direct insight into the results and can continuously adjust deadlines and effort to complete a product. So what is important when analysing agile projects? We have compiled the most important agile key figures.
KPIs for time optimisation
Time optimisation is a fundamental part of improving work processes. These KPIs help with this:
Cycle Time
Cycle time describes the time that is spent on the actual processing of an order when using Kanban methods. In contrast to the lead time, which covers the entire period from receipt to the end of the order, the cycle time only describes the time during which work is done directly on the implementation of new requirements. More precisely, it includes the active implementation of changes in the software. Using the cycle time as a key figure thus enables a detailed view of the actual software development processes and helps to optimise them: the shorter, the better.
Velocity
Velocity is an important factor for the work organisation of Scrum teams_._ It is about predicting how many tickets can be delivered within an iteration, i.e. a sprint. The more precise and realistic the team's estimate is, the more exact the value will be. The individual tasks are evaluated with the effort in hours or the abstract unit Story Points. After a sprint, the completed tickets can be compared with the estimated value and the velocity calculated. In this way, the productivity of a team can be observed over a longer period of time.
Velocity tracking is especially important for the planning of the individual organisational units to enable a smooth flow of work processes. It helps to refine the estimates and predictions of the individual work steps and to work more efficiently. However, due to individual estimations and the different definitions of story points, it is difficult to compare the KPIs of individual teams. The velocity KPI and its improvement should therefore only be understood as a planning tool and not as a rigid target.
Process-oriented KPIs
The following KPIs can be used to monitor development processes and thus the success of the individual steps.
Sprint Burndown Charts
A sprint burndown chart is used by Scrum teams and indicates the amount of work still to be done within a sprint. The approach here is the other way round: not the tasks already completed are listed, but the remaining work until the set goal is reached. This indicator can also be used to detect any planning errors that the team may have made in the initial phase.
Release Burndown
The release burndown is not only used by Scrum teams, but also by developers who use Kanban. Like the sprint burndown, the release burndown also deals with the time span and the work done or the progress made. However, the release burndown covers a longer period of time and is only completed with the release of the developed software. Burndown charts are also suitable for its representation, with which problems can be quickly identified and the entire development process can be mapped.
Cumulative Flow Diagram
The Cumulative Flow Diagram used by Kanban teams is not a metric in itself, but a powerful tool for visualising them. It brings together different aspects such as the planned workload, the processes currently being worked on and the processes already completed in order to analyse them. By reproducing the entire work process, the diagram not only provides information about the current development status, but also allows bottlenecks to be identified and thus enables further planning to be optimised.
KPIs for output control
Crash Statistics
After the release, crash statistics are important key figures to make the success of the software measurable. The average time between the occurrence of errors and error correction or the frequency with which an application crashes are possible KPIs here. These can also be viewed against a temporal background: The goal here is to keep the number of incidents in a certain period of time as low as possible and their average processing time as short as possible in order to demonstrate an improvement.
Code Coverage
Code coverage is a key figure that compares the number of tests actually carried out within a code with the number of theoretically possible tests. The calculation of this KPI is technically relatively simple and the evaluation is also simple: the higher the code coverage, the better. However, when using this KPI, one should bear in mind that the development team can influence the indicator by randomly testing as large a quantity of source code as possible.
Less control, more progress
Although the key figures offer the possibility to monitor work processes in detail, they should be used less for control and more as indicators for possible further developments. The most effective use of KPIs only results from a consideration of trends and rarely from a direct comparison of parallel developments. Under certain circumstances, their use can even be detrimental to team motivation, which is why the benefits and results should be carefully weighed up.
