Removed Sprint Items in Burndown Chart

Whether the Development Team adds or removes work from the Sprint Backlog, shouldn't the burn-down accurately  reflect remaining work? Hence I would treat the removed tasks as 'burned'.

Be careful with the term commitment. A Development Team should commit to a Sprint Goal rather than completing every task on their plate. If a team completed every task but delivered no value or poor quality, then how important is that?

How should removed Sprint Items be reflected in the Burndown chart? Currently, we use trello and manually fetch the data. Should they be treated as "burned" or should we adjust the commitment data from day one?

It seems odd that a team would commit to a forecast of work, considering that it might well change. Team members might more reasonably commit to shared goals.

They should have a clear view of the amount of work that is forecast to remain. What problem does the removal of items cause in this regard? Might a burn-up chart provide better transparency?

Keeping in mind that this would not affect velocity, as it is not really part of your work done. 

I've seen this too many times unfortunately, where half of the items were discarded but still concidered as velocity, leading into false input information.

Don't remove anything from the Sprint.

If it's in the Sprint at the beginning or Sprint then do now move it.

If it's added to the Sprint during the Sprint then also leave it there.

There are some cases where items can be swapped out during a Sprint e.g. a 3pt Story for a different 3pt Story. This can only be done by Development and not the SM or PO.

Don't remove anything from the Sprint.

If it's in the Sprint at the beginning or Sprint then do now move it.

If it's added to the Sprint during the Sprint then also leave it there.

What would you say about transparency in this case and how it affect the ability to truely inspect and adapt?

In the 2011 (from the top my head) version of the Scrum Guide, the word 'commitment' to planned items has changed to 'forecast'. Now taking a look at your remarks here, what can you say about why this change has been made? 

When we say Forecast we mean that: we believe we can deliver these items in the next Sprint based on the data and estimates we have given.

This does not change. 

The items in the Sprint should still not change.

What if new insights/learnings occur? Not changing anything is like writing things in stone and not adapting to new learnings. Puting it in an extreme perspective;

Let's say we're planning to go from A to B over the highway. The highway has three lanes. We plan to drive down the right lane as we believe this is the safest path. We truly believe this, so this forecast will not change. Now we start driving and while we are driving, we see that the person in front of us crashes, making us crash if we do not adapt. BUT, because we have forecasted and made a promise to not change this, do we then plow into the car in front of us?

This is only for the timeline of a single Sprint, things do not change that quickly. Common sense should also come before process, if things change that quickly and dramatically inside the Sprint then make the change.

If things are changing that drastically and quickly during a 2 or 3 weeks then you may have some other issues to fix.

Common sense should also come before process, if things change that quickly and dramatically inside the Sprint then make the change.

So common sense supersedes the rule you have suggested, although not a rule you'd find in the Scrum Guide.

If things are changing that drastically and quickly during a 2 or 3 weeks then you may have some other issues to fix.

What's sorts of issues are referring to?

What do you do with items that are added during the Sprint?  Are they not included in the burndown chart because they were not part of the original prediction?  A burndown chart is just a tool to help someone see how much work is left to do based on the work that has been identified in order to complete a deliverable. It isn't an indicator of success or failure. It isn't an indicator of velocity.  It isn't much more than a graphic view of your task list. Quit trying to make it some kind of magical thing. 

If you add items to your Sprint Backlog, they should show on the burndown.  If you remove items from the Sprint Backlog, they should be removed from the burndown. 

Picture the burndown chart as a loaf of bread in a bag.  As you remove a slice of bread, the loaf gets smaller and the bag becomes less full.  Doesn't matter whether you eat the slice, crumble it up to feed to birds or throw it away.  It is no longer in the bag.  If you had another loaf of bread in a separate bag and decided to combine them, the single bag gets fuller.  In the end all you really know is whether you have enough bread to eat for the next week or not.

If things are changing that drastically and quickly during a 2 or 3 weeks then you may have some other issues to fix.

I totally disagree, especially (but not exclusively) in contexts where the Sprint Goal is outcome focused, where the Development Team is responsible for analysis and UX, where there are multiple increments produced per Sprint, and where outcomes are being monitored throughout the Sprint.

Imagine a team with a Sprint Goal to increase the click-through rate from one page to another. They might have prepared Plan A, based on what was known at the time, and might simultaneously perform other product discovery, such as A-B experiments, user interviews and so-forth.

What should a team do if the evidence shows that Plan A will not have the desired effect on user behaviour, but there are more suitable ways of achieving the same goal?