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?

4 Answers 4


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.

  • FWIW There is no such thing as a "project backlog" in Scrum, I believe you meant Product Backlog. A Sprint should not be terminated early excepting rare conditions, finishing the work forecast early is not a reason. scrumguides.org/scrum-guide.html#events Commented Sep 23, 2016 at 14:38
  • Fixed to product backlog. Regarding the early-termination, while I agree it shouldn't happen, if the team estimates for 2 weeks and ends up completing everything in 2 days, early termination is probably the best way to go there. Like I said, it shouldn't be a very common occurrence.
    – Sarov
    Commented Sep 23, 2016 at 14:50
  • "Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened." scrumguides.org and PMSE pm.stackexchange.com/a/20202/20712 Commented Sep 28, 2016 at 13:13

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.

  • I like your answer, and suggest the reference to product backlog refinement meetings as a clarification. I am not convinced that one needs to be asking the business (product?) owner if he considers the project complete at each sprint after the "must haves" are done. Maybe such would be the case only if the team was getting close to some budget/time constraints. I did not, however, suggest editing that, as it didn't seem my place to do so.
    – David
    Commented Jul 9, 2015 at 7:52
  • @David - My perspective is that if you wait to ask "are we done?" until you are pushing up against your budget or schedule you aren't taking advantage of every opportunity to finish early or under budget. Personally, if there is an option to finish under budget/ahead of schedule, but with consequences to non-necessary scope items, I feel obligated to lay that option out.
    – Doug B
    Commented Jul 9, 2015 at 12:13
  • I see your point, @doug. here is a question I posed for people to address that specific issue of completing a project after the "must haves" are complete.
    – David
    Commented Jul 9, 2015 at 22:40

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

  • 1
    "have user stories [...] constantly being bumped [...] or pulled back" Rather than simple intra-sprint story prioritization, it seems the problem there is just excessive movement of stories in/out during a sprint. No one but the Dev Team should get to say 'Okay, the Dev Team commits to this.' The Dev Team should have full control over authorizing this. If they don't, that's the problem. If they do, the problem is that they're not saying 'No.' nearly often enough.
    – Sarov
    Commented Sep 22, 2016 at 19:21

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.

  • When using the Scrum framework, there should only be the Sprint Goal. "The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives." The Scrum Guide Commented Sep 27, 2016 at 17:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.