When a SCRUM team works on stories from multiple projects, you should have several burn-down charts:
- One chart indicating the progress on the stories within the current sprint. This chart is updated daily by the team to indicate how they are progressing to the sprint-goal of that sprint. Where the stories on the chart come from should not matter for the chart.
- One chart per project to keep track of how the project is progressing towards its release date. This chart is mainly for the project manager(s) to keep track of the progress of their project(s) and should be updated only when a story for that project is delivered by the team.
The velocity measurement is SCRUM is meant to give the team a measure for how consistent they are estimating the amount of work/complexity that they can handle in a sprint.
This can only work if there is a single golden standard to use as a reference for a unit of work/complexity.
The golden standard can (and will) differ between teams, but it should be consistent within a team, even if that team works on stories from different projects.
The recommended way to establish such a golden standard is to pick a story of medium effort and give that 3 story points. Then you estimate all other stories relative to that golden standard.
You should not have stabilization sprints. Your software should be releasable every sprint. This means that if you need stabilization, that has to happen within each sprint and not just before a release. Once you achieve this, release planning becomes a product owner concern ("What features to I need in order to release?") and stabilisation a team concern (definition of done).
The same applies to bugs and technical debt: it's stuff that is always fixed, as needed and does not require stories -- in fact, it's normally part of each story: it can't be "done" unless it's stable and properly refactored.
I realize that this does not answer your question directly, but stabilization is not an agile concept at all, so it makes no sense to ask how to do it with Scrum.
Edited to address comment:
According to Scrum, bugs found pre-release are to be handled within the iteration. A story is not normally considered "done" if it has bugs. If you can't ship it, it does not have value. Also, according to basic Agile principles, teams should work at a sustainable pace. If you need to basically stop development in order to address debt or bugs, then you are not working at a sustainable pace. Decrease your velocity, ship less features, but without bugs.
Usually stabilization happens in teams that have a separate QA team checking features post hoc. This does not fit in the Agile or Scrum model. Teams should be cross-functional and able to ship a feature independently.
Overall the thing is, many companies say they do Scrum or Agile without understanding the deep changes it entails in the way software is built. If you are not prepared to build software according to these methodologies, don't use it as a "management add on" on different practices.
Best Answer
There are a few things wrong with the situation described, the obvious problem being the lack of respect given to the back-end developers. As this question is tagged agile I am going to push back on other answers suggesting this is only a social problem. There are several bad smells and possible anti-patterns in your story, none of which have to do with ignorant management or even how you slice the stories.
The fact that a group of individuals on the team feel slighted for not getting glory from work completed smacks of several possible problems.
My recommendation is to treat architecture as a first class citizen -- but do it the right way. Perform a quality attributes workshop with stakeholders. Involve key stakeholders in architecture reviews, or at least summarize essential design decisions at important milestones. Draw the architecture on big paper and make it visible so the entire team can see it.
Require that everyone develop everywhere in the system (front-end and back-end), pair program if you need to so this can happen effectively. Continue to create user-focused user stories. But also identify key quality attribute scenarios that show why the system is designed the way it is and drives decision making regarding "back-end" design. Elevate the architecture design so that it is not invisible anymore.