Software development is not deterministic, i.e. it is impossible to repeat the same experiment and always get the same result.
Let's take a trip from city A to city B as an example: even if we make this trip hundreds of times, we won't get the same result every time. Since this is not deterministic, we have to be probabilistic. It's a bit like a weather forecast: what are the rain probabilities on Wednesday?
A projection is made of two essential elements:
- a probability
- a period (of dates)
Can't we simply make a linear projection to know when we will deliver?
This may be satisfactory for teams that can maintain a continuous work in progress (WIP), that rarely violate Little's Law assertions, and that do not classify tasks by level of urgency (Classes of Services). For the others, i.e. the majority of the teams, we will use a Monte Carlo simulation.
Monte Carlo?
Imagine that you are working on a project running for some time. You want to know when you will deliver a specific feature. You could rely on your intuition to estimate the delivery date or extrapolate with a line, but that won't consider variables that may affect the delivery.
Imagine instead that an army of 1000 analysts produces different scenarios for you:
- What happens if we work slower?
- What if we work faster?
- What if we finally discover that there are more items to do?
- Or that there are fewer items to do?
This army of 1,000 analysts looks at the probability of the different scenarios and then chooses the desired (or most likely) scenario.
Now imagine that you don't need to pay those 1000 analysts and that you can get the answer right away? That's what Monte Carlo simulation can do.
This technique is better than your intuition and better than simple regression models.
With this technique, you can now make your projections in two ways:
- What is the probability of completing all these items by X (e.g., May 3, 2022)? → Possible answer: You have a 42% chance of reaching this date.
- When will these items be delivered? → Possible answer: We have an 85% chance of delivering these items between April 10, 2022, and April 30, 2022
I already use Jira. What else does Axify offer?
Jira's strength is its Agile project management. Although it already has charts like the Burndown/Burn-up chart, the Cumulative Flow Diagram, and the Control Chart, these are not perfectly adapted to stabilize the team.
- Burndown/Burn-up charts: The flaw in these charts is that we come to rely on the trend and the average. Past performance does not guarantee future performance. These charts are also used to make projections. These projections are often linear (pessimistic scenario and optimistic scenario). These do not meet the definition of an estimate and are less relevant than a Monte Carlo simulation.
- Control chart: This graph shows the trend of Cycle Time over time. The shortcoming of a Control Chart is that it is often based on a mean or standard deviation (which is itself based on variance). While relevant, outliers have a reasonably significant impact on the result of these formulas. Instead, Axify uses percentile-based charts. Outliers happen once in a while and should not be removed from our analyses. On the other hand, if they don't happen often, they shouldn't have as significant an impact since they are not representative of reality. This is why graphs based on averages are significantly affected by outliers, which does not help the team to stabilize.
- Cumulative flow diagram: This is one of the most advanced graphs for analyzing the Lean flow of a team. It is generally used to detect trends. It is not necessarily effective in predicting the future and would be limited to a linear projection. Moreover, it may not be representative enough when there is insufficient data.