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?”

  • 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 🙂 ).
  • 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.

One thought on “The Sprint Burndown – WHY? Part I”

Leave a Reply

Your email address will not be published. Required fields are marked *