New stories added in Sprint Backlog - Should I update the Burndown chart?

I agree that making changes to the Sprint backlog is not a good idea

How is that? How can you account for emerging work if you don't want to change the Sprint Backlog?

But if new stories are getting added into the Sprint Backlog then how should I manage the Burndown chart?

That is simple I guess, if something is added to the sprint, something else is removed, about equal size. So the burndown chart roughly stays the same, right?

Thanks Xander for the reply.

What if SPIKE are added during the sprint? How it will impact the Burndown chart?

What if SPIKE are added during the sprint? How it will impact the Burndown chart?

Is there is difference between spikes, stories, bugs or any other work item added to the sprint?

Making changes to the Sprint Backlog may be normal. Consider what the Sprint Backlog is - a set of Product Backlog items plus a plan for delivering the product Increment and meeting the Sprint Goal. At the Sprint Planning session, the Product Backlog Items are selected based on the team's capacity and what the team can forecast they can do. Then, the team begins to develop a plan. However, the Daily Scrum gives the team opportunity to "inspect and adapt" the plan. I would expect that the Sprint Backlog may change at a Daily Scrum, if not more or less frequently.

However, what I would not expect is for the selected Product Backlog Items to change frequently. Although I wouldn't go so far as to say they should never change, a change should be rare. To me, changing the Product Backlog Items selected for a Sprint, especially on a shorter Sprint cadence, would seem to indicate that either there were significant changes in user needs that were unforeseen or that the Product Backlog was poorly ordered going into the Sprint Planning.

As for how to manage the Burndown Chart, it depends. Are you burning down Product Backlog Items or tasks or something else? I would expect a chart to reflect reality and show accurate increases and decreases in whatever is being tracked, whether that's Product Backlog Items, Sprint Backlog Items, points, or whatever. The same goes with Spikes. You need to understand what the axis of your Burndown Chart is and how to make something useful to stakeholders.

I agree that making changes to the Sprint backlog is not a good idea.

Why? Is it better to allow a forecast of work to become irrelevant and out of date?

But if new stories are getting added into the Sprint Backlog then how should I manage the Burndown chart?

Might you find a burn-up chart to be more helpful?

Also, how Spikes affect Burndown chart?

Spikes are often done for the purposes of Product Backlog refinement. Would you expect this activity to impact the burn rate at all?

That is simple I guess, if something is added to the sprint, something else is removed, about equal size. So the burndown chart roughly stays the same, right?

Hi Xander, I have question on your above statement. Why is it necessary to remove something from sprint backlog of equal size ? I mean is it even important to remove something at all ? New emergent work that arise can be related to the PBI itself which is needed to move this item to done. 

I agree that making changes to the Sprint backlog is not a good idea. 

I actually encourage changes to the Sprint Backlog because it shows emergent information is being acted upon and that the plan for delivering an increment that supports the Sprint Goal is being adapted as the work is done. From the Scrum Guide section describing the Sprint Backlog.

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

And this from the section discussing the Daily Scrum:

The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. 

If the plan is being discussed on a daily basis I fully expect that the plan can change which should be reflected in the Sprint Backlog in some manner.

As for the burn down chart, isn't the purpose of that chart to represent the amount of work left to do against a time measurement? If you are not updating the chart to reflect the actual work, is the burn down chart serving it's purpose?  I'm not a fan of burn down charts but I do know that others see benefits in them. But any benefit is lost if the data is not reflecting reality.

In my opinion Spikes shouldn't be included on any kind of chart unless you include some kind of measurement for all refinement activities that you undertake.  Spikes are for the purpose of refining Product Backlog items and not for delivering work related to the increment that supports the Sprint Goal.  I truthfully don't feel that Spikes are valid items to appear in Sprint or Product Backlogs.  

I prefer a noisy Burndown. Visualize everything the team is doing and facing. The data is important.

You don't deliver 'clean' burndowns, so don't bother trading stories either. Show the plan and show how it changes as the team works and learns things. Allow the team to make the decisions that best serve the Sprint Goals. External influences that affect the Sprint should also be added to the Burndown so the team can retro on how they want to handle those scenarios.