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?
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:
...because predictability is an important quality in Scrum.
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:
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.
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.
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.
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.
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.
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:
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:
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.
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:
