The Sprint Burndown – WHY? Part II

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.

Last time, we talked about the basics and the core why behind the Sprint Burndown. Now, let’s talk about the Sprint Backlog in more depth, and at the same time move towards the bigger picture of metrics and audience.

This post answers questions like, “Can I, as a manager, use the Sprint Burndown to gauge the performance and progress of the team?”

  • Understand that a burndown is a crude, single metric – so there’s a lot of conversation that needs to come along with it. That is, just having a Sprint Burndown, even if it’s accurate and up-to-date, is rarely enough to-know-where-you-are (see the previous post about why this is an important need). For an example, enter the Daily Scrum – if the SB looks good today, but Jimmy is totally stopped on a huge, key task, for example – the team should hope they’re not just looking at the SB and saying “looks great, moving on…”, and they should hope Jimmy is speaking up (or at the very least, the Scrum Master is helping facilitate that), because things are not “great.” That’s not where they actually are, regardless of what the SB says.
  • That said, the SB is useful all by itself as a trigger for explicit adaptations – “we’re not where we thought we would be, even a crude metric like the Sprint Burndown can show us that – what are we going to do?” If you’re not using it as a trigger to adapt, and just looking at a drift from the ideal trend line and saying things like:

    “Well, maybe it will get better.”

    or

    “Let’s just work harder!”

    or

    “It’s really not that bad, I’m about to close 4 tasks and then the line will go down, trust me…”

    – then I actually recommend you stop using it immediately, because you’re not doing anything with it that’s intended – you’re not really believing it (you might say you’re not actually inspecting it), and most importantly you’re not using it to adapt. You’re wasting your time, and you or someone else is likely drawing conclusions from it that are very dangerous because they’re so detached from reality.

  • This “problem” (it really isn’t a problem, it’s just the nature of the thing) – that the SB isn’t all that useful by itself, other than as a trigger for more granular discussions around adaptations made in response to its inspection – is much greater, with even more implications for the outside (of the team) observer of the SB. Anyone outside of the team should be very careful about drawing any conclusions without additional information from the entire team. “Don’t draw sweeping conclusions from isolated metrics,” is one cliche that applies here. You can probably start to guess where I’m taking this…
  • The SB, when used, or any other how used to meet need-to-know-where-we-are, is explicitly for the team, as one tool that will help guide them to meeting their Sprint Goal. Outside observers don’t have enough context for it to mean anything of value to them by itself, and for the team to add the context would involve so much time on their part (it would go well beyond just observing the Daily Scrum) that you may as well put the outside observer onto the team – which is impractical for all sorts of reasons, and not what the outside observer is after, anyway. Even so, I oftentimes see managers and others outside of the team trying to use one simple thing, like a Sprint Burndown, to draw conclusions that have nothing to do with what’s being tracked, or the actual goal of the artifact in question.
  • The questions and conclusions I see these outsiders trying to understand – whether the team is successful and performant, whether they need help and what kind of help, whether medium- or long-term goals are in jeopardy, whether we’re happy with the return on investment of this team in the context of building this product – are all very good things which I encourage you and them to understand. A Sprint Burndown, quite literally, tells you none of these things. Let me repeat:

    A Sprint Burndown, quite literally, tells you none of these things.

    Trying to use it for these means will be very frustrating for people outside of the team, because it just won’t work. Trying to use it for these means will be very frustrating for people on the team, because that inevitably comes across as (and most often actually is) micromanagement.

OK, so I’ve said that the SB is not the tool for understanding these things, but also that these things are still valuable – so, what are some good tools to understand these things?

Next time we’ll talk about the answer to that question, which will also actually help us understand more about the Sprint Burndown.

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.

Normalizing Story Points NEUTRALIZES Story Points – Agile Estimation Problems and Myths, Part 1

Sometimes teams, and now well-accepted frameworks, misuse and misunderstand agile estimation concepts at a deep level, to the extent that all of the potential value of the practices is stripped away. This series will talk about theory, whys, and whats behind some of the concepts and practices, and allow you and your teams to take back the power and value of agile estimation techniques!

Remember, eight Story Points means two days for our team!

– Many an individual Scrum Team

With a team of 5 coders and testers, use a Velocity of 40 points per Sprint.

– A suggestion a currently well-accepted scaled agile framework might make

flat-icon-mountain-sheep-normal-goats-goatBoth of these statements fall victim to multiple misunderstandings regarding Story Points. I’ll call the two scenarios described here “normalizing Story Points,” as that’s a reasonable umbrella term to cover them both. They are slightly different, though, so I’ll also cover some of the differences below.

There are fundamental issues with normalizing Story Points that remove the advantage of, and any possible need to use, Story Points – that is, normalizing Story Points also neutralizes Story Points – it makes them useless.
Continue reading Normalizing Story Points NEUTRALIZES Story Points – Agile Estimation Problems and Myths, Part 1

Scrum is Chess, Part II

518px-ChessSetIn my previous post, I mentioned that I’ve been getting a fair number of questions lately that go like this:

What does Scrum say about [[ something that Scrum does not prescribe anything for ]]??

Questions are always good. I think I’m dealing with some clients who are a bit more self-aware, Continue reading Scrum is Chess, Part II