Agile Metrics: Burnup with trend lines
In another post, “Agile Metrics: Burnup and Monte Carlo how to follow the evolution of your project?” I talked a little about the burnup chart, but in this, I would like to bring a new element, which is the trend lines.
Remembering
The Burnup chart is widely used to monitor projects with a fixed date or simply to forecast when a number of tasks will end up based on the speed of delivery of past items.
In the post mentioned above there is a graph like this:
What’s new
Unlike the last Burnup, in addition to the average throughput (number of items made in a time cycle) we will also look at the values:
Minimum: Smallest number within a data set
Maximum: Highest number within a data set
Mode: Number that is more repeated in a data set
Median: It is the value that separates the major and minor half of a data set
Percentile: It is a measure used to divide a sample of values, ordered in ascending order, into one hundred parts.
We will use this data to create 3 lines on the chart, which will be responsible for showing 3 types of possible scenarios:
Optimistic: using the best or closest to the best team performance.
Realistic/Likely: Uses the most balanced data, excluding extremes.
Pessimistic: Using the lowest performance scenario.
In the end, we will arrive at a graph similar to this:
Orange: Corresponds to the backlog, and as you can see in the graph above, it shows the evolution of the backlog over time. This can give you a good insight into project planning. In my analysis, I notice that the project started with 20 items and until the last check (September 2) it has already doubled in size with 43 items. If this growth continues at this pace, it may likely become a risk that may compromise the delivery date.
Yellow: The number of deliveries accumulated over time. Analyzing the columns, I see that between August 5th and 26th, the team increased its throughput, but the other week it didn’t deliver anything. In this case, it is important to evaluate what happened to avoid these throughput losses, we know that there are things that are beyond our control, but it is good to always keep them registered for future analysis and, if possible, create action plans to avoid these situations.
Green, Blue, and Red: Matches the trend lines (Optimistic, Realistic/Likely and Pessimistic).
Pink: In this case, it corresponds to the expected delivery date, if the trend lines go beyond this bar it is time to raise the red flag and see what they can do to return the lines behind the pink column. In the case above, only the pessimistic line (red) has passed the date, in my analysis, it is not something serious yet, but it already alerts me to possible risks.
Observation
At the beginning of the project, it will be very difficult to make decisions just by looking at the graph, because the data set will be small, but as the project evolves, the graph already starts to make more sense, as the data becomes more visible.
The blue table to the side shows the data that can be used to create the trend lines.
In this case, my choices were the ones that appear below:
For an optimistic line I decided not to use the maximum because the 8 was an atypical case of delivery, I preferred to use the 75th percentile to be more conservative and realistic with the history of the team’s delivery.
For the Likely, I got the average because it is the most balanced data.
For the pessimist, I kept the median which was the lowest data excluding the minimum which was 0 and therefore I would not be able to build a trend line with this value.
What we need to understand is that during the development of the project these choices may change. The purpose of the tool is to help us gather insights into the project’s health based on data. And it is very important to understand the context and the source of this data.
It’s not the graph that will be responsible for delivering projects over time, but our choices and attitudes.
Caution
If your team has a very large standard deviation in throughput, try to investigate the reason for the variability and try to decrease these standard deviations before using the graphs.
Another point is not to use this tool to charge for delivery, but to guide and help you find the risk of delays such as dependencies, increased scope, loss of team engagement, etc. And you will only know this information by investigating, it will not be the graph that will provide these answers. It will simply initiate a signal that the project is not going where it should.
A phrase I usually say:
Contextless data is just numbers
Tips and Links
You can find the link to the spreadsheet presented here. It is very simple to fill and just add the data once a week.
But I know that nobody likes to fill out spreadsheets, the good news is that if you use Jira I have good news, today there is already an integration between Jira and google spreadsheets, to learn more just access here.
I hope this article helps you in some way, and if so leave your feedback or contribution in the comments.
