Marek has been a Product Owner for a year and a half. His team is building a new billing feature. With sales, it is agreed that the thing will be ready by the end of October. Every two weeks he sits in a meeting with three stakeholders and hears the question: So, are we going to make it?
Marek has no good answer to that question. He has a feeling and answers out of it, but the feeling changes from Sprint to Sprint. What Marek is missing is a picture that answers the question without him having to answer it. That is what release burndowns are for.
I (Anton here) want to describe in this post why I no longer generate these burndowns out of Jira (or any other ticketing system), even though there is of course a feature for it, and at the end I will hand you a tool you can use instead. Over my career I have tried three times, in three different organizations, to run an automated release burndown in Jira, and I failed three times.
What goes wrong
A release burndown lives a long time. Ten Sprints is normal, and at two weeks per Sprint that is twenty weeks. In that time something at the ticketing system can change that is not in your hands, and it will destroy your burndown without any way back.
The first organization had more than 1000 employees. We used the “Epic Burndown”, which is what the feature is called in Jira for producing a release burndown, for five months to communicate with stakeholders across three levels above us. It worked well. Then it broke out of nowhere. I searched for months and to this day have not found out what caused it. All I know is that some setting on our Epics was changed. The most important admins sat on another continent and had entirely different concerns. When we talked to them, we got nowhere.
The second organization had 30 people. I had been closely supporting the Product Owner there and was the one responsible for the burndowns in Jira on his behalf. He renamed some of his Epics and tidied them up a little. After that the burndown was useless. The third case resembles the second, so I will not tell it.
There is no way back. The structural change takes away your view into the past. You could take a screenshot every Sprint, but from the moment it happens you are rebuilding everything by hand. I tried that three times and gave up three times.
Every further structural change creates the same problem again. And in none of the three cases did anyone make a mistake. Admins did their work, a Product Owner refined his Epics. That is exactly his job.
Why this burndown matters to me
The value of a release burndown lies in the fact that it stands for a long time. Marek shows his stakeholders the development in the same picture for twenty weeks. They get used to it. Over time, trust and understanding grow out of that.
In every undertaking, more wishes appear as time goes on. Someone just has to talk about it. When Marek’s stakeholders see for four Sprints in a row that the burndown is not burning down but burning up, it becomes easy to say: we are taking on too much, let us decide together what drops out.
For that, the picture has to be simple and easy to understand. As soon as the numbers get complicated and longer discussions start, the conversation is lost. Then everyone talks about where the data comes from instead of about the scope of the version. A burndown that an outsider cannot read in ten seconds produces exactly that discussion.
A tool like this has to be an information radiator (a term coined by Alistair Cockburn). It radiates its information outward, you do not have to go looking for it. A release burndown out of a ticketing system is the opposite. You have to open it, and you have to know what is being counted and what is not. That these systems can be configured so freely is their great strength and, here, their weakness, because nobody on the outside knows how they are set up.
How I do it
Once per Sprint I record a single number: the sum of the points still open for the topic of the burndown. Always at the same moment.
I used to do this shortly before the Sprint Review. Today I would recommend doing it right after the last Refinement, because that is where the estimates are freshest. More important than the choice is that it stays the same moment every time.
If you have a ticketing system, you set a filter there on the topic of the burndown, and it gives you exactly this number. So you do not have to count.
There is one precondition. Everything belonging to this deadline has to be estimated. The estimate may be rough, it just must not read “100+”, because 100+ can also mean 1000. This holds regardless of the tool. Whatever method I use to hit a deadline, I need at least some rough idea of how much effort sits in the work before that deadline. Whether that happens in an agile or a classical way.
The fair objection
The data is already in the system. Why enter it by hand into a spreadsheet a second time?
That is a fair objection. My answer is a trade-off. On one side stands the effort: one number per Sprint. On the other side stands a tool that builds trust over months, and the risk that it dies out of nowhere. For me those two are not in proportion. One number every two weeks is cheap.
How the spreadsheet works
Over the years I have built my own Excel files for this again and again. Here is a more general version of them.
That it is Excel and not an app matters. An app would be a black box again. Excel shows every calculation openly, and most managers can work with it.
You enter the values of your Sprints, starting at Sprint 0. Then you set two numbers. Both sit visibly in the sheet, not hidden inside a formula.
- Up to which Sprint you have real data. From the next Sprint on, the sheet computes the forecast.
- How many of the last Sprints that forecast should be based on.
The second number is what makes the difference in daily work. Marek has six Sprints behind him and knows that the first three struggled with entirely different problems. So he tells the sheet to use only the last three, and sees immediately what the forecast looks like then.
To be fair: the spreadsheet only solves the part of the problem that has to do with traceability. It does not take away the discipline of entering a number every Sprint. And if nothing is estimated, it does not help you at all.
[release-burndown template download]
Which path fits whom
If you administer your ticketing system yourselves and nobody has touched the Epic structure in years, you will get by with the built-in burndown. Just check whether your stakeholders really understand what they are looking at.
If the administration sits somewhere else, or if you are only just earning your stakeholders’ trust, write down one number per Sprint.
And if you do not run a burndown at all so far, the question of the tool is secondary. Start, with whatever you have.
I am glad to get responses, critical ones included.
Disclaimer: The spreadsheet above is mine, and I am happy if you use it and talk about this post. The post itself is not a criticism of Atlassian or Jira. The problems described arise in ticketing systems generally. For maintaining the Product Backlog there is no way around these systems.
On the word “release”: I use release burndown because it is the established term. It is a slightly misleading one, because it suggests deploying to production. What is meant here is any agreed scope with a deadline, and you should of course still deploy as often as you can.
PS: There is a thought I keep coming back to, and I will just put it here. Whether someone can maintain a release burndown over time, with their team and their stakeholders, and communicate about it, would be a fairly comprehensive test of fitness for the Product Owner role. Anyone who keeps that up for ten Sprints is necessarily having both conversations: the one with the developers about what the options are, and the one with the stakeholders about which wishes this version serves. The test moves away from the abstract question of whether someone merely holds the authority, toward the practical question of whether the person has the skills and the resources for it. Very often someone has the power but not the time. That is exactly when the role should go to someone else. I do not know whether this interests you. If it does, write to me and I will work it out.