The Sprint Burndown – WHY? Part I

This series will talk about the WHYs behind a commonly used, misused, and abused concept in Scrum: the Sprint Burndown. A Release Burndown is an entirely different thing, with different goals and a different audience, which these posts will not cover at all. The confusion between these two burndowns, especially understanding the different audiences, is one thing that leads to misuse of the Sprint Burndown.

Let’s start with the basics.

This post answers questions like, “I feel like the Sprint Burndown is a waste of time – we don’t use it for much – can’t I just stop using it?” and “If this is all about remaining work, where do I track the hours I actually worked today?”

• • A Scrum Team needs a way to understand where they are in relation to their Sprint Goal and the work they forecasted for the Sprint (what’s on the Sprint Backlog), at any and all times during a Sprint.

• • Without this transparency, there is no opportunity for valid inspection, and therefore no opportunity to successfully adapt. There’s a reason the team meets at least once a day, in the Daily Scrum, and it is not about individual team member status. It is about understanding where you are as a team, and as a team figuring out what to do next to achieve the Sprint Goal. If where-you-are isn’t where-you-thought-you-might-be, what are you going to do about it? Inspect and adapt, inside a 24-hour window, to get to the right place in the 1 to 4 week window (the Sprint) – that’s what we’re after. Without a transparent sharing and understanding of where you really are, and the ability to respond to inevitable uncertainty even in a window as short as a Sprint, you will never get to where you want to be. All of this is the why behind the expectation in the previous point, and that’s always important (I’ll talk a lot more about this throughout this series of posts, as the title suggests 🙂 ).

• • The Sprint Burndown is about tracking only the team’s current understanding of the work remaining, so the members can adapt based on that reality.  It’s about reflecting current learnings and truth of the work in the Sprint, and keeping focus on, “What’s left?  How do we complete this and deliver value?”  The “actual” or “burndown” line of the SB (as opposed to the “ideal trend” line) does not reflect how much work has been done.  Doing work, putting in hours, tracking the hours you worked – those things are somewhat interesting, and you may need to track them (I get it, I’m a consultant), but they have literally nothing to do with the Sprint Burndown.  I may have worked 8 hours on a task I originally thought would take 4 hours, and still have 6 hours left by my current estimation and understanding.  So, “6” goes into the remaining work field of that task (A corollary to this is: a team with burndowns that never burn up, day after day, Sprint after Sprint, is telling itself a lie – building software is in the complex domain, and estimates will inevitably be wrong at times, even in time horizons as short as a Sprint or a task).  The fact that I worked 8 hours might be interesting to a manager or accountant, especially if we’re capitalizing the work I’m doing, but I should completely ignore that in regards to the Sprint Backlog and any tasks contained within.  If you have to track this, I’d strongly recommend you track it in another system to avoid confusion and maintain focus on what each activity and tool is for.

• • A Sprint Burndown is a common way in the Scrum world to satisfy this know-where-you-are need – most every tool supports it (not that that makes it a good idea per se, but it does make it easy), and it kinda-sorta-used-to-be an official Scrum Artifact. It is no longer, because an SB is but one way you might achieve the goal – so “knowing where you are” is the expectation, how you do that is up to your team. (That is not the same thing as saying the team could choose not to meet the expectation (and be unable to inspect and adapt inside a 24-hour window), or use something that is not accurate or useful, either – enter a good Scrum Master who can set expectations about what is needed and why, without having to prescribe any particular how.)

• • One example of a different how than a Sprint Backlog: some teams size their tasks to be no larger than x (oftentimes, a single day / 6 to 8 hours), and simply use the count of tasks in the Done column vs. the count in the To Do and In Progress columns of a task board to tell them where they are (a simple count drives things, not hours/effort/size as in the y-axis of the most common type of Sprint Burndown). No Burndown is built – just take a quick glance at the board – how does it feel, now that all task post-its are roughly equal? Sure, go ahead and count them if you need to. Good enough. Note that without the explicitly small/bounded task sizing, and instead with a huge range in task sizes, this rarely works – it tells you very little about where you are.

• • Another example is using test reports (usually focused on Acceptance Tests) and comparing passing and failing tests – the context with this one is a truly test-driven environment (beyond just unit tests via TDD – thinking about “test-driven” in a holistic, comprehensive way work is approached). This often means there are test(s) for each Acceptance Criteria, shelled out (and initially failing) directly inside of Spring Planning, etc. – in this case, “done” for a Sprint Backlog Item / story is a report where all of its tests are passing (functional side, roughly), and it meets the Definition of Done (non-functional side, roughly). This is an incredible place to be, when an entire team is focused on making something work exactly as the customer is expecting / would accept – and the focus is continuously, relentlessly on that. It helps teams not lose focus on minor technical debates, etc. But I digress.

Next time, we’ll talk about the Sprint Backlog in more depth, and at the same time move towards the bigger picture of metrics and audience.