xProcess has a very flexible mechanism for defining priorities using "Priority Groups" which allows any Folder or Parent Task which has been "prioritised" to support ordering of tasks within it. Each Priority Group can be given a "weight" so that all the priorities can be combined into the ordered list that the scheduler uses. As with many of the very flexible mechanisms in the product, when you actually tailor the product for a given process (Basic Scrum in this case), you have to make some decisions about the normal way to use the features.There are many different way to use Priority Groups, some of which have been incorporated into the standard processes released with xProcess. For example the Simple Process has the facility to add "High", "Medium" and "Low" categories to the project so that just by categorising tasks they get prioritised appropriately.
Basic Scrum defines Sprints as prioritised Parent Tasks with diminishing weight (later Sprints therefore have lower weight and are scheduled after the earlier ones). As you've observed when you move a task from one Sprint to the next the priorities they had in the previous Sprint gets lost. So if this is a normal part of your process - I can understand why it could be - why not define another prioritised group (say a Folder called Release Backlog) where you can give your stories a longer lasting relative priority. The weight for this group does not need to be high because it will just be the "tie-breaker" when stories have the same priority in Sprint. I think this should achieve what your aiming for.
... the Story will contain defects of level 3 severity or less only ... Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.
Let's look at the consequences of this policy.
Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…