Jacqueline: Our letter for today is B is for burndown, and let’s extend that to include burnup. B is for burndown and burnup. Usually along with that comes a connotation of a chart or a report. You have a burndown chart in agile and a burndown report or vice versa, a burnup chart and a burn up report. It’s commonly used in scrum and in other flavors of agile.
Listen to the Podcast – B for Burndown Chart in Agile
On the surface it’s pretty straightforward. A burndown chart in agile shows how much work is remaining to be done in the project. You’re burning down based on what you’ve estimated as what needs to be done. You’re burning down. If that’s in story points, let’s say you are burning down to a release, and that release might have X number of features. Those features are estimated at story points. Each feature may be 40 story points. In your release, you’re going to have two features, so that means you have 80 story points. So if each sprint you’re burning down an average of 20 story points, you can see as you take away off of that 80 points.
Let’s explore a little bit more, because there’s always more to the story. Foremost, when you’re doing your burndown chart in agile, you use your x-axis (that’s your project iteration timeline) and your y-axis (that’s the work that needs to be completed for the project). The time or story points estimated for the work remaining will be represented by the y-axis. The project’s start point is the furthest point to the left of the chart and occurs at day 0 of the project. Your end point is the point furthest to the right of the chart and occurs on the predicted last day of the projection. The number of workers and the efficiency factor is how you determine your velocity. What you’re doing is you’re tracking your estimated velocity early on or your estimated days and points per sprint. And then you refine that over time to come out with the average or median.
The whole purpose of the burnup and burndown chart in agile is so that you can have consistency in your estimating. Over time, you learn what factors impact your velocity or your ability to deliver on your total story points. For example, there are an estimated 28 days of work to be done, and there are two developers working on the project who work at an efficiency of about 70%. Therefore the work should be completed in 28 divided 2 divided by .7, and that equals 20 days. Keep in mind the efficiency number, for example 70%. If there are distractions or other work that’s outside of the project work, if there are administrative tasks, o if they’re going to training that number can fluctuate greatly. At the start point the ideal line shows a sum of the estimates for all the tasks that needs to be done or needs to be completed. At the end point the ideal line intercepts the x-axis, showing that there is no work left to be completed.
Some people take issue with calling this the ‘ideal line’, as it’s not generally true that the goal is to follow this line. The line is a mathematical calculation based on estimates, and the estimates are more likely to be in error than the work. The goal of the turndown chart is to display the progress toward completion and give an estimate on the likelihood of timely completion. If anything, instead of just trying to push yourself toward that ideal line, you can, in retrospect, look back at what factors kept you from keeping on the straight and narrow, on the ideal line. Those are the things that, from a scrum master and a management team, how to keep those roadblocks and those distractions from keeping programs from giving their 70% or accepting that they’re part of the reality and it’s ok. To learn more, you can visit our page on daily scrum meeting.
This is so important for scrum masters. It’s not just to keep pushing people to keep trying to work toward the ideal line but better understanding and communicating up to management why there are some exceptions to the estimates. This is a tool for the scrum master, and scrum masters who are properly taught that their role is to protect the team, not pressure them This isn’t the old project management command and control where you set dates and milestones and pushed the team by any means necessary. It’s quite the opposite. You want to communicate up to management those things that are causing distractions from the velocity of the team, those that are justified, and then those that can be managed.
I hope this gives you some new insight and to burnup and burndown chart in agile. It can be used for good. It’s valuable. It’s important for your progress. It should be a point that people rally around to celebrate progress, not to punish those doing the work.
For more information, check out our other podcasts
ExpressoTechSip – One Slide At A Time – Can You Scrum With A Remote Team?
ExpressoTechSip – One Slide At A Time – How To Avoid Hiring an Agile Coach
