How volatility helps to identify problems in development at an early stage

If requirements change, this can cause major problems. Therefore, "attention should be paid". But that is easier said than done. After all, we are not only talking about customer requirements, but also those in the design or architecture.

These potential problems can be identified (and averted) early on if we monitor the volatility of requirements during development. This is one of the patterns that I on my ReConf presentation will introduce.

Goal

The aim of this pattern is to recognize at an early stage whether changes in the project could lead to problems so that proactive action can be taken.

Motivation

Even if we would prefer to prohibit changes, we are confronted with them more often than ever. Changes to customer requirements are still the easiest to handle. After all, there is someone (the customer) who explicitly addresses the change.

More difficult are changes that arise in the development chain, be it through a different solution approach, a new technology or even a change in architecture. If they are not drastic, smaller changes are not explicitly addressed, but can still have a long tail behind them.

The good thing is that the degree of change can be measured. This is known as volatility and can be generated automatically. This is particularly important in large teams, as individuals often do not realize that the degree of change exceeds a critical threshold. If such a situation is detected via volatility, those involved can be made aware of it, for example to agree on interfaces at an early stage in order to contain the effects of the changes.

Definition of volatility: Number of changed elements in relation to the total number of elements, per time unit.

The specific calculation is described below (structure).

Areas of application

In order to make sensible use of volatility, you must:

• elements can be grouped in a meaningful way (it makes little sense to measure the volatility of a Word document)
• Relevant changes can be recorded (e.g. the change from "Complete" to "Approved" should not be taken into account)
• The evaluation is automated and regular.

Structure

In order to capture volatility, a tool is required that enables atomic work with individual elements. This would be Jama, for example, when it comes to requirements, or Jira when it comes to user stories. With reservations, it can also be used with non-atomic elements, e.g. lines of code in software development.

It must also be possible to analyze the data over time. A 24-hour cycle has proven itself in practice.

Finally, relevant changes must be recorded during this period. These are usually additions, deletions and edits. When editing, you should qualify which attributes are relevant for volatility: This is certainly the descriptive text, but not necessarily status or priority.

With this information, volatility can be calculated as:

This should be plotted on a timeline for analysis so that the development can then be tracked regularly (e.g. weekly).

Effects

New projects typically have a high level of volatility, as many elements are added and edited in the early stages of development. However, the volatility should then decrease as development progresses. Shortly before completion, or directly after reviews, there are usually small peaks, and the curve flattens out after delivery. A "healthy" volatility could look like this:

Here we see how the number of requests (gray) rises quickly at first and then stabilizes. The curves in red/orange/yellow show the number of changes, additions and deletions. This shows the volatility in blue from.

In contrast, here is a picture of "unhealthy" volatility:

Implementation

In order to be able to measure volatility, it must be possible to manage atomic requirements and recognize relevant changes. This is basically the case with any sophisticated requirements tool such as Jama or DOORS.

The volatility data must then be analyzed in a graph as shown above. There are tools that can do this. The graphs show the volatility of requirements in Jama Connect, evaluated in Jama Analyze.

It is important to record the correct groups. For example, user needs, system requirements and design elements should be recorded separately for each project.

Photo by Leio McLaren (@leiomclaren) on Unsplash
Graph images by Jama Software