Should sprint backlog have MoSCoW prioritization applied?

Question

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?

Answer 1

No. Don't do that.

Only the tasks in the product backlog could be prioritized via the MoSCoW method. If one were to do as you suggest, trying to get a distribution of priorities in the Sprint backlog, then the Team will be ignoring those project-priorities.

Consider the situation where there are 6000 must-haves, 2000 should-haves, 1500 could-haves, and 500 won't-haves in your project backlog. You then start a sprint, with an actual velocity of being able to take on 20 stories (in this hypothetical scenario, all the stories have identical story-point costs). If you were to use the MoSCoW method for the sprint backlog, then during that sprint you would end up accomplishing 12 must-haves, 4 should-haves, 3 could-haves, and 1 won't-have.

Comparing that to the alternative of taking simply 20 must-have stories into the sprint, I think it becomes obvious which approach is better. Assuming constant velocity, the MoSCoW-sprint method will take 500 sprints to complete all of the must-haves, while relying only on the backlog priorities would complete them all in 300 sprints (again, assuming this hypothetical situation where every story requires equal effort and nothing blocks anything).

If a Development Team runs out of work during the sprint, then the Product Owner should be informed and either the sprint should be concluded early or more work should then be added to the sprint. This should, ideally, not be a very common occurrence. If a Development Team consistently under-estimates work for their sprints, then there are issues with their estimation process.

Answer 2

Features/capabilities/deliverables/tasks should have been prioritized (in the product backlog) using MoSCoW during requirements gathering prior to starting your first sprint, and as required during subsequent product backlog refinement meetings. During such refinement meetings, you may want to revisit this prioritization, but that is more asking the question "Is item X still a must have?" rather than having some arbitrary percentage being must-haves, should-haves, etc.

What you should see is a decreasing number of must-have stories in both your product and sprint backlogs as you move through the project. Once you get to the point that you have zero must-haves left in the queue you should be asking the business owner if he considers the project complete at the end of every sprint.

Answer 3

I am in an organization that is Scrum-ish, like so many other places that go from doing these Waterfall/Traditional and end up wanting to implement Agile.

We do a similar prioritization for all Iteration planning sessions, we have 15 day iterations and call out Need to Have/Nice to Haves based on the committed hours, which is absolutely hellacious on burn down and velocity as you have user stories/tasks/defects constantly being bumped to a next iteration's release or pulled back into the backlog to make room for something with a higher "business" need.

So do not do that, you should be doing it when you are finishing up requirements and positioning it in the backlog during your Domain Walk/Sprint Planning meetings

Answer 4

That's too fine-grained. The acceptance criteria should depend on must-haves, only.

It might be ok to also have "stretch" goals, depending on how you are defining the sprint goal and selecting items from the product backlog.

For example: if the sprint goal is "implement functionality X", then the stories and the AC are strictly limited to the minimum needed to implement functionality X. However, if there are related small tasks in the product backlog that (per the PO) would make X nicer, or implement a closely related functionality Y that would add value to X, then I think it's fine to identify them at sprint planning time, keep them in mind as you work, and pull them into the sprint if and when a) you have completed all the planned sprint work b) with enough time left that you are confident you can complete the stretch task.

This might be more of a scrum-ban approach, I suppose.

That said, it will mess with your velocity calculations, so if that's important to you, don't do it. (Even if you account for the added story points when you add them, there's a methodological difference between "we attempt X points in Y days and our velocity was X/Y" and "we attempt X points in Y days and finished early, so we took on another Z points because we were sure we could get it done, woohoo".)

Finishing a sprint early also allows the team to use that time to catch up on tech debt and do other non-sprint work, which has its own value.