In my Scrum Master Certification training, the trainer mentioned: "Even though the Sprint Burndown is being deprecated it is still used by many teams". The reason behind (I guess) was that it tends to produce micromanagement and going back to control based estimation and planning. What are some alternatives?
In two weeks Sprints my team currently uses a Sprint speed graph.
Each day after the three questions, the team asks itself how on track they are against their Sprint goal. They have 4 options:
- Super: We will do more stories than estimated
- Sprint: We will finish the forecast
- Goal: We will meet the sprint goal
- Bad: We are behind and need to take action
We draw this metric unto a graph on our Scrum-board. We also try to take action if we are hitting a low Goal or Bad.
Overall I think it gives a more honest feeling about what we are going to complete. It makes the whole team think about where we stand daily.
Why do I favour this above burn downs. Most burn downs start late from the beginning as the first days you have not completed a story. Giving a continuous feeling that you are behind. Therefor I favoured burn-ups, but the Sprint speed adds even some more value.
Here at first we thought we would made our full sprint forecast. Then we noticed the biggest tasks was going to be a lot bigger. Now we know we will not make the last story out of 6. On Monday we start communicating with our client. Together we decided to move on and finish the complex story as it still the most important.
You can find my Excel sheet with colours here.
There is nothing wrong with a Sprint Burndown. There is nothing wrong with any, team-based metrics. Just as there is nothing wrong with a car, so long as you use it as a car and not a can opener.
The problem is that team metrics, like the burndown, are often misused by management. I'll have an article on this subject going live on AgileConnections.com late next month (I'll edit in a link when it posts), which is a follow-on to this months article recommending team metrics. The summary of next month's article is, "With great power, comes great responsibility."
The purpose of a Sprint Burndown is for the team to review their progress towards the sprint goal and ask if they need to do anything to change it. That's it. Any other use is abuse.
If you are in an org where you can't use a burndown, it's not the burn down's fault, it's the organizations. A sign of deeper issues.
A lot of teams are progressing into continuous flow models of development where there is not a timeboxed sprint. Teams are also moving away from projects with an end of project "maintenance mode" toward product development teams that are active throughout a product's life time. Burn downs are good for shorter term projects where there's a "finished" state, but fall a bit flat in this newer paradigm.
Because you don't really need to know when the project will be done, but rather when the customer can expect a feature to be in their hands, folks are replacing the burndown with burn ups, culmulative flow charts, and lean based Lead Time metrics.
I'll let you research those things else this answer would turn into a quite lengthy blog post.
If you do month long sprints as in the original Scrum, a sprint burn down is useful because you want to know how late you're going to be!
But the trend today is to shorter, week long sprints. When your sprint is just 1 week you don't care about knowing how late you wil be in advance.
You just work out how late you were last sprint and adjust estimates accordingly.
Let's provide an answer that summarizes most of the comments related to the question and some answers.
According to Scrum Guide, the only reference to burn-like diagram is the following:
"Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making"
Therefore there is not an explicit recommendation, nor is it considered an artifact of the standard. Said that because it is a tool for the team, not for any external stakeholders, if the team decides it is a good tool to communicate the progress, it is up to the team to use such kind of tools.
Burn-down vs burn up: Both of them are equivalent if there is no change in the Sprint scope. Here is a good explanation about the difference, but if there is the expectation to have changes in the Sprint backlog, during each Sprint, it is more suitable to use Burn-up diagram. Burn-down, focus on simplicity (just work done) and Burn-up focus on information (provide information about work done and scope changes). Here is another good article the recommends Burn-up too.
If there is the expectation to have too many changes, another option would be to consider using Kanban framework, that is more suitable when is likely to have changes in the sprint scope.
@JoelBancroft-Connors pointed: Nowadays the general trend is to use Sprint of shorter length such as: 1-week sprint, in such cases to use a tool to visualize the progress has less relevance.
@RubberDuck, mentioned a good alternative is to use Cummulative Flow Diagram it counts the number of items delivered after a certain period of time.
@NielsVanReijmersdal suggested the use of Sprint speed graph: Each day after the three questions, the team asks itself how on track they are against the Sprint goal. They have 4 options: Excellent, good, OK and bad. We draw this metric unto a graph on our Scrum-board. We also try to take action if we are hitting OK or Bad.