The software development market continues to grow from a high of $466.8B in 2019 to an even higher $507.23B by 2021.
As the world continuously changes and grows more turbulent – COVID-19 being proof of the turbulence the world is capable of – dynamic approaches to software development are essential for rapid iterations and responding to changes.
With changes in traditional methods of software development came newer metrics which are required to calculate the efficiency and responsiveness of modern software development. The earlier traditional method operated on the assumption that all stages in the development process are quantifiable. Modern analysis broke from this pattern by incorporating metrics to involve the newer software development process.
This shift is giving rise to Measurement Leaders who go beyond using KPIs to determine how to organize their company. Instead, they use KPIs to identify opportunities for growth and ways to motivate their teams better. Therefore, this modern, newer way of software development with modern metrics calls for greater team communication, cohesion, and continuous evolution.
What are the modern KPIs or metrics that Measurement Leaders are using?
Modern Metrics and Their Benefits
Modern metrics are defined by their ability to track the software’s success beyond the development stages. This ensures client interaction and keeping the client at the center of the project at all times. While there are several modern metrics that a project manager can track, we have identified a set of key metrics that a project manager should take care of first.
One of the foundations of modern software development remains working in sprints. A sprint burndown then becomes the graphical representation of the amount of work towards a goal completed during a sprint. It visualizes the teamwork done and the teamwork yet to do. This is measured through the ideas of effect-hours and the number of days within the sprint. Effect-hours are the number of hours it takes to complete User Stories – the smallest unit of work in the modern analysis. Immediately, stakeholders and potential clientele play a big role in determining the effort-hours.
The graph includes a vertical axis with the remaining effect-hours and a horizontal axis with the days within the sprint. An estimation is first provided and then lines are charted depending on the reduction in effort-hours over each day in the sprint. The resulting graph shows a trend of the likelihood of completing a task early or later than the projected deadline. In the former case, the team can add more User Stories and tasks to their sprint burndown. The goal is to finish all the effort-hours by the last day in the sprint.
Team productivity is measured through inputs and outputs. While inputs are easy to measure, outputs are not always the case i.e. the number of lines of code does not necessarily equal productivity. Cleaner code often requires more planning.
Productivity is often conflated with velocity i.e. the ability to put product backlogs back on schedule. This is not necessarily an accurate measure since it can often indicate productivity easily and create false conceptions. Instead, some metrics to measure team productivity are:
- Achieving most sprint goals
- Delivering value equal to the financial investment in each sprint
- Working at a sustainable pace i.e. finding the perfect balance between underworking and overworking while delivering value
- Acquiring deep vertical specialization so one person can take on greater loads in certain tasks, allowing the rest of the team to spread out in other specializations
- Learning quickly and regularly through the learning loop (assume, build, feedback, inspect, and adapt), therefore adapting to new important information easily
This refers to the entire design process as well as stages within the process. If stages are added, then the time can increase. This is important throughout for effective sprint burndowns and a better calculation of the lead time and time-to-market (explained below).
This is relatively easy to measure – have a stipulated idea of the time it will take for delivery and then an actual measure of time for delivery. Similar stages i.e. stages where the kind of code is similar or elements of the project cross over can be clubbed together with the same stipulated delivery time. This then gives you an idea of when the project will be finished. Various projects can also give you an idea of your on-time delivery (OTD) rate, as explained above.
This KPI measures the capabilities of each individual within a project. It measures productivity as the number of user story points per developer per sprint. Keeping track of individual employees’ contribution towards User Stories through the sprint burndown chart or from the team gives you an idea of whether an individual is underperforming.
Combining this with the vertical specialization that team productivity can be measured through elaborates on their capability and why they may be underperforming. Since modern management involves team productivity, taking up individual performance with the team is the best way to tackle the problem. While this may not be a quantifiable metric, it is a surefire way to determine development success.
Bug/Application Crash Rates
This KPI determines the success rate. Also called defect density, this refers to the number of defects in lines of codes that affect any User Story. In an ideal world, every individual story would be tested. However, in reality, this rarely happens which means watching the rate of escaped defects and the trends on a graph becomes a good indicator.
These crash rates are primarily measured through crash-free sessions i.e. how many sessions of interaction one can have with an app before it crashes. Here, a 99.5% success rate is typical before an app can be declared bug-free.
Issue Open/Close Rates (MTTR)
MTTR or the Mean Time to Repair rate refers to the average time it takes to repair a system application. In other words, how long it takes to close an issue with the software. Ideally, as DevOps mature, the MTTR should get lower and lower.
This is often contrasted with the Mean Time to Failure (MTTF), which indicates the amount of time between failures. Experts argue that the MTTR is more important since customers care more about how quickly they can resume use of the application rather than how much time passes between failures. E.g. if the software has an MTTR of a few seconds with an MTTF of once a week, this is better for the client than an MTTF of every 5 years with an MTTR of 24 hours.
MTTR can be calculated by adding the total time it took to repair issues within a given period and then divide that by the number of issues.
Lead time refers to the duration of time between task creation and completion during the planning and execution of User Stories. It ties into Time-to-Market (TTM) as the metric measuring how long it takes for certain software to hit the market. It also includes cycle time i.e. when the work on the task begins and task completion. Calculating or estimating lead time creates a better idea of sprint effort-hours.
Since tasks may be created for later project stages at the beginning of a project, lead time measures them from that point while cycle time begins measuring time once the work to complete that task begins. The total lead time (which incorporates cycle time) becomes the TTM. This then gives you an indication regarding the execution capabilities of your team. Additionally, it indicates the lead time for similar tasks in the future, tying into individual performance and team productivity.
Why Modern Metrics are Critical
Now that we have established certain modern metrics that determine project success, we also need to understand their importance. While we said earlier that traditional methods cannot bring your business success, we need to explore why. What makes modern metrics better?
Better Project Planning
The first result of using modern metrics is better project planning. According to one critical report, 97% of companies have incorporated modern metrics into their project planning in some way, allowing project planning to be flexible and enabling team cohesion. As a result, delivery time is perfected through sprint burndown charts and there is high efficiency with project teams constantly learning and bettering themselves through their various performance-based KPIs.
Better Performance of Developers
The metrics also ensure better performance by the developers. Since the KPIs measure both quantitative (e.g. lead time) and qualitative (e.g. individual performance) factors, they keep the team engaged and invested in software development. Additionally, with close intel and continuous reviews from stakeholders, their efficiency and performance of development teams are improved with a faster turnaround on new features and bug fixes.
Through measuring the KPIs and bettering planning and performance, better outcomes are guaranteed. After undergoing this development model and the related KPIs, the project success rate is higher than the failure rate. Deadlines remaining adjustable and constant checking in for risks through MTTR and MTTF make the project manageable with a clear plan. The kind of success developers ensure through these KPIs further reflect the business’ success rate, too.
As industries become more client-centrist and incorporate non-linear approaches to their projects, project managers and development teams adjust accordingly. The best and most successful businesses are defined by their ability to change with the times and meet demands adequately when they arise. This makes them ideally placed to tackle the future through modern KPIs. In this category are Fortune 500 giants like IBM, Microsoft, Cisco, and T&T, all of whom have incorporated the KPIs we discussed and improved their business outcomes. If it worked for them then clearly these modern KPIs must be doing something right!