SCRUM states that the team should commit to delivering the stories in the sprint backlog. It is implied that once they have reached this limit, no more items are added to sprint backlog.

Should the sprint backlog be openly prioritised using MOSCOW prioritization? So that the product owner's expectations for X% of the spring backlog tasks were as follows:

• 0-60% - Must have stories
• 61-80% - Should have stories
• 81%-100% - Could have stories
• 100%-120% - Stretch tasks (for team to do if they move exceptionally fast)

From what i can see, this approach benefits from:

1. Automatically building feature contingency into sprint estimates
2. Giving team option of over achieving through stretch tasks

However, this approach complicates the concept of teams commiting to delivering the whole sprint backlog.

Does anyone have any input on the advantages & disadvantages of this approach to sprint planning? Or experience implementing something similar?

Scrum states that the team should commit to delivering the stories in the sprint backlog. It is implied that once they have reached this limit, no more items are added to sprint backlog.

Should the sprint backlog be openly prioritized using MoSCoW method? So that the product owner's expectations for X% of the spring backlog tasks were as follows:

• 0-60% - Must have stories
• 61-80% - Should have stories
• 81%-100% - Could have stories
• 100%-120% - Stretch tasks (for team to do if they move exceptionally fast)

From what I can see, this approach benefits from:

1. Automatically building feature contingency into sprint estimates
2. Giving team option of over achieving through stretch tasks

However, this approach complicates the concept of teams committing to delivering the whole sprint backlog.

Does anyone have any input on the advantages & disadvantages of this approach to sprint planning? Or experience implementing something similar?