The story a sprint burndown chart told me

Understanding what a chart will tell you

Before I share some actual burndown charts, it’s helpful to make sure we’re on the same page. A burndown chart will show you how much work is remaining within a sprint. Some teams will use an alternative burnup chart, which shows work completed against time. That then is usually a different view of the same information.

How our burndown charts showed what was wrong

The following are three real charts from our sprints. Taken from Jira, I’ll tell you the story behind each one. How we got to that situation, questions we asked in sprint retrospectives to inspect and adapt, to work out what we were doing wrong.

  • How are you visualising the workflow? Are your user stories too large or the tasks too granular? Is our process too complex or have too many steps?
  • Are you using the Scrum events well? Are the team self-managing effectively to ensure a sprint goal is on track?
  • Are there impediments or bottlenecks? How can the scrum master step in, or better still, help the team to self-manage?
  • Could we bring in some Lean ways of working, namely Kanban? Would using flow metrics or setting work in progress limits help? The Kanban Guide for Scrum Teams can help with this.
  • Are we using the Scrum events properly, particularly the sprint planning meeting?
  • Is the PO working with the team closely enough to properly refine the product backlog, ordering the right items by value?
  • Are we selecting the right items for the sprint backlog? How can we make better decisions in the future?
  • Are we managing stakeholders well and setting the right expectations on when we will do the work? Does the scrum master need to coach stakeholders to understand how Scrum works?
  • A two-part question: first, is Scrum the best framework for the team? Second, could we enhance our Scrum with Kanban, particularly if the organisation’s environment is changeable?
  • Are we over-committing each sprint? Should we narrow the goal and the focus of the sprint?
  • How is our stakeholder management? Are we waiting too long for feedback?
  • Do the team have everything they need ahead of working on an item? Is there enough understanding of how to meet the definition of done?
  • Are we spending enough time on our estimation and planning? Is that causing an overcommitment?
  • Are we using the daily scrum effectively? What steps could we take earlier in the sprint to ensure we progress and raise issues earlier?

How we moved forward

By asking all these questions, we could get under the skin of what was going on. These conversations gave us insights burndown charts could never provide. It was empiricism, not burndown charts, that helped us become a better team. The three pillars of empiricism are transparency, inspection and adaption. Our journey took us in a new direction, one where Kanban and flow helped us deliver better and more valuable outcomes for our product.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Agile Alex

Agile Alex


Hello! I’m Alex, a product manager based in the UK. This is my blog about product and agile.