I am currently managing a software product. I am using scrum/agile. The problem that I am having is that I am unable to create an accurate burn chart, because the backlog keeps on being updated with new items.

For example, a typical scenario that tends to happen is when a item is begun, and during the sprint it is discovered that the item is underestimated leading to the item being split into more backlog items leading to my burn chart to be inaccurate.

How do I handle situations such as this?

5 Answers 5


With more items being added/split and re-estimated with more knowledge seems like your burndown is becoming more accurate rather than not.

Issue you are facing is that it looks like it is not burning down but rather up. This is ok as long as the overall trend is down and you are confident that you can complete your work by sprint end.

If you are not confident (the current line is way above the ideal), then the burndown is working where it is telling you that you will not reach sprint completion. Knowing this sooner can give you the opportunity to descope items, talk to the team and react accordingly. Without a chart this would be discovered too late.

The purpose of a burndown chart is not to burndown perfectly, but to tell you daily that you can meet your sprint completion.


It is fine when your burndown chart goes up, because it highlights a problem, that you have to address, during a retrospective meeting. Your team should get better at planning, and until you have spikes in your burndown, you'll know that your efforts of fixings this, weren't good enough.

Here is what I would do:

  1. draw the spike into the burndown
  2. let the team be surprised about it and do not let them to change how they work - if they think it is important to break down a work item, so be it
  3. the next retrospective would be about planning, and spikes in burndown
  4. keep doing 1-3 until you reach a state that satisfies you

...because predictability is an important quality in Scrum.

  • I would add a caveat here - a certain amount of predictability is useful, but as with everything, there are diminishing returns. If a team can quickly and easily quantify their "planning optimism" - say, 20% overage on most sprints, they could choose to factor this into planning rather than taking on more and more overhead in digging deeper in every retro, adding new processes, etc. Sometimes finding the sources of overage reveals actionable info (such as mid-sprint feedback or lack of trust/autonomy), but the actual planning aspects can be separate. Nov 10, 2015 at 23:06
  • You are right, I'll update my answer.
    – Zsolt
    Nov 11, 2015 at 8:01

You can take steps to minimize unpredictability

In software development you are always working on things that are to some extent new, even if it is not an entirely pioneering effort. Even if your team has successfully completed similar projects, this time you may have to work with a newer version of the operating system, different frameworks and tools or integration with a different third-party component. So, there is always an element of discovery - unlike say in the construction industry - which gives rise to some unpredictability.

This is the reason why the Scrum Guide was revised in 2011 to change the word "Commitment" to "Forecast".

However, while you cannot eliminate unpredictability fully you can take steps to minimize it:

  1. Backlog refinement: The Product Owner and the Development Team should collaborate on refining the Product Backlog items. The team can spend upto 4 hours per week (not more than 10% of the capacity) in doing this. Use this time to understand the business goal and write-up the user story and acceptance criteria well. Also, split the stories into more manageable and better understood smaller ones.

  2. Sprint Planning: In addition to the above prep work, the team can get additional clarifications on the user story and acceptance criteria during the Sprint Planning. In my experience putting more effort on "story ready" helps a lot in minimizing the uncertainty.

  3. Time-boxed Research story (spike): If the work is substantially new and different from what the team has done before, schedule a time-boxed Research story (also known as a spike). I have always used 4-hour time boxes. The development team can use this time to build a prototype or a proof-of-concept so that you are able to estimate better and when you schedule the main story your risk is much lower.


How to Use Burn-Down Charts Correctly

The problem that I am having is that I am unable to create an accurate burn chart, because the backlog keeps on being updated with new items.

For example, a typical scenario that tends to happen is when a item is begun, and during the sprint it is discovered that the item is underestimated leading to the item being split into more backlog items leading to my burn chart to be inaccurate.

You have several misconceptions here about the purpose and content of a burn-down chart. I will try to clarify them for you, and to provide some guidance on how to properly manage and interpret a burn-down chart within the Scrum framework.

  1. Changes to your burn-down chart make it more accurate, not less.

    You are incorrectly assuming that a burn-down chart that isn't trending down is somehow inaccurate when in fact it is accurately describing a change in scope and work remaining. This is simply information, and is inherently neither good nor bad. The team (including the Product Owner) should use this information to determine whether the work remaining can still fit within the current sprint, or whether this represents a threat to the Sprint Goal that should be addressed by cutting scope, removing stories, or calling for an Early Termination and a return to Sprint Planning.

  2. A Sprint shouldn't generally include new user stories.

    Once a Sprint has started, a story can be refined and tasks added to the Sprint Backlog. However, as a rule of thumb the team should not be adding whole new user stories to the Sprint Backlog, except when all other work has been completed early and the Sprint Goal has been met. This is not what you're talking about.

    Splitting large stories, or uncovering prerequisite stories, is certainly something that happens in real-life Scrum implementations. However, mature Scrum teams know that these stories should be carefully reviewed by the whole team, including the Product Owner, to ensure that:

    • The newly-discovered work is relevant to the current Sprint Goal.
    • The additional work or changes in scope do not threaten the current Sprint Goal.
    • The team has the capacity to incorporate the additional work.
    • The additional work actually belongs in the current sprint, and not on the Product Backlog.
  3. Burn-down data is schedule/planning/status information, not a management target.

    When a burn-down chart trends upwards during a sprint, this is information for the team. When the burn-down chart makes it clear that the work remaining in the current sprint exceeds the time or capacity remaining, then it is a call to action. These actions may include:

    • Identifying the estimation problems as an issue for the next retrospective.
    • Triggering a discussion with the Product Owner about the scope and objectives of the current sprint to determine the best way to meet the Sprint Goal with the time/capacity remaining.
    • If the Sprint Goal can no longer be met for any reason, the Product Owner should call for an Early Termination of the sprint. The team should do a retrospective to discuss the problems encountered, and then replan a new sprint armed with better information.

    Treating the burn-down chart as sacrosanct, or as a management target that must be met at all costs, is entirely missing the point of the artifact. It's a communications and planning tool that is meant to provide transparency into the process, rather than a stick to beat the team with. Always treat the burn-down chart as information, rather than as a scheduling tool (e.g. a Gantt chart), and you will find it much more useful.

  4. Burn-down charts should have the appropriate granularity.

    A burn-down chart is not required by the Scrum framework; it's simply an agile practice that is very common. As a result, you are free to adjust the granularity of your chart, or to use multiple charts, to suit your needs. For example, you may find that tracking the burn-down of stories (rather than tasks) gives you less day-to-day variance while still providing an accurate picture of the team's overall progress.

    Alternatively, you may choose to track both stories and tasks on the same chart. For example, a single chart that has a green line for stories and a red line for tasks might be useful in communicating where the scope creep is, and may even help the team determine where scope needs to be trimmed if the Sprint Goal is at risk.

    It's worth noting that the volume of stories or tasks in a burn-down is not necessarily a scheduling issue. If you're tracking tasks, and the burn-down shows a rising number of tasks on the Sprint Backlog, it's still only a problem if the work remaining exceeds the time box of the sprint. In many cases, the number of work items increases, but the additional granularity allows the team to complete each item faster, resulting in no net change to the overall sprint or the point at which work-remaining will reach zero.


A burndown charts works fine on a well defined Scrum iteration: there aren't new things being added. Unfortunately, this is very hard to happen (as you point out on your question).

My suggestion is: give up on using it. You can choose one of these two other tools, instead:

  • Burnup Chart. Probably what you need, for now. Easy to spot what's being accomplished and also the scope change. A good comparison between burnups and burndowns can be seen here.
  • CFD (Cumulative Flow Diagrams). A more sophisticated tool to show you how your work is progressing. A brief explanation about it can be found here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.