I have a question regarding backlog grooming. I have completed product prioritization using MoSCOW method. I have it prioritized it as follows. I have rationalized it working with client and gathering other data.

enter image description here

Question: Now, I am in the sprint backlog phase (sprint planning for the next sprint) and assume that I have 3 developers. How do I create sprint backlog atleast the bare structure. Do I have to pick ONLY Must haves for sprint backlog or use 60% of MUST haves and 20% of should haves and rest 20% of could haves for grooming?

How do you go about this? Do you use some other technique? I am super confused how to go about this. OR should I get into the meeting with this information and let the development team create sprint backlog as they wish (my gut says the team will not appreciate it).

For the purposes of this question, I havent added user stories, acceptance criteria. do assume that I will be writing user stories in reality.

  • 1
    It seems like you are a Product Owner. Why do you have things labeled as "3rd Sprint"? Why are you trying to create a Sprint Backlog? Using words like "Sprint Backlog" and "Sprint Planning" imply Scrum, but you also don't appear to have a Product Backlog and you only have one person on the Development Team, which seem to make Scrum not a good fit.
    – Thomas Owens
    Commented Nov 26, 2019 at 0:21
  • @Thomas Owen's. Yes I am a PO. What I have shown you is a product backlog with must, should have and so on. Is that wrong by any chance?please let me know What I mean by 3rd sprint is the upcoming sprint. Let me change 1 developer to 3.
    – SPO
    Commented Nov 26, 2019 at 0:26
  • 1
    My concern is that I don't know where this information is coming from. The Product Owner does not allocate Product Backlog Items to Sprints or assign estimates (in points or others). A Product Backlog is also prioritized - why is a should have below a could have? The Development Team needs to provide the estimates, hopefully of Product Backlog Items that meet the INVEST criteria
    – Thomas Owens
    Commented Nov 26, 2019 at 0:35
  • 1
    The PO doesn’t control the Sprint Backlog. Only the Development Team can do that.
    – Todd A. Jacobs
    Commented Nov 26, 2019 at 0:52
  • 1
    Yes - a Development Team is responsible for estimating items, or even decomposing items into smaller items as necessary, and then pulling them into Sprints when they have the capacity. And I used the word "prioritized" wrong - the Product Backlog is ordered, which considers not only priority but also dependencies. Something that a product should have is prioritized above a could have, but there may be a technical dependency that causes a could have to be ordered first.
    – Thomas Owens
    Commented Nov 26, 2019 at 1:52

5 Answers 5


In order to do Sprint Planning, you first need a Product Backlog. What you have is not sufficient to act as a Product Backlog.

The Scrum Guide defines a Product Backlog as "an ordered list of everything that is known to be needed in the product". It appears you have this, but Product Backlog Items are more than just brief requirements. Product Backlog Items are ordered on the Product Backlog, considering priority and dependencies. Product Backlog Items are also continually refined by the Development Team and Product Owner to add details, estimates, and improve the ordering. One characteristic is that higher ordered items tend to have more details and more precise estimates than lower ordered items in the Product Backlog.

Looking at what is referred to as the Product Backlog in the question, I see a few things that stand out. The "items" aren't very clear - they appear to be simple requirement statements that have not been refined by the team. I would expect a conversation between the Product Owner and Development Team to add detail, and perhaps even decompose items into multiple, smaller items that can be designed and delivered independently - after refinement, Product Backlog Items often meet the INVEST criteria. I would also not expect Product Backlog Items to have an estimate until after they have much more detail than shown here. The assignment of Product Backlog Items to Sprints is not something that is done by the Product Owner - this is done by the Development Team at Sprint Planning.

What you're presenting is, in my opinion, insufficient for Sprint Planning. Refinement with the Development Team must happen first. After Refinement, the Development Team will have enough information about the items in the Product Backlog to start to make well informed decisions about what they will be able to accomplish in a Sprint. Over time, they can include historical data to further improve their decision making.


You have a lot of extraneous information in your question. If you have a prioritized backlog, we can assume that doing the work in the order given will provide the highest ROI. Therefor, unless the team has specific reasons that the order must be changed, I'd look for them to pull in the first item, then the second if it fits, then the third, and so on.

Now, this gets complicated a little bit by sprint goals and trying to build increments of value as opposed to simply outputting code, but the foundation is always the same.

  • do you mean I must ONLY have must haves in my sprint backlog. What happens to should and could have? Do I have to prioritize them in the sprint wi4h bunch of other feature ideas, bugs and legacy that may come in? Please let me know.
    – SPO
    Commented Nov 26, 2019 at 0:33
  • 1
    @SPO, you should view the product backlog as a stack of paper with one backlog item per sheet and the priority going (from top to bottom) from most to least important. The sprint backlog of the next sprint will then be formed from the top-most sheets until you have reached the team's capacity. Commented Nov 26, 2019 at 12:57
  • I agree with Bart. MOSCOW is a great way to order that stack of paper, but it doesn't come into play when executing.
    – Daniel
    Commented Nov 26, 2019 at 15:59

I'll add my voice to Bart and Daniel, and go a step further: I do not use the MoSCOW method at all for the very reason of eliminating the confusion you are feeling. My teams had no trouble, and actually preferred just getting a rank-order like Bart describes. I have POs use whatever method they like to determine the business value for rank ordering, but categorizing like High-Medium-Low has caused more problems than it solved among my clients.

To meet the comments about the quality of your requirements, consider writing them all as user stories (or old-fashioned "use cases"): "As a [user], I want [specific feature/action], so that [purpose]." The literature on epics generally describe them as still being user stories, just too big to complete in a sprint. I also train my clients to add proposed Acceptance Criteria, the proof you will need to see to accept the story, usually in a single (high-level) sentence. However, the final language of both the story and the criteria should be negotiated with the team during sprint planning, both to respect their self-management and to ensure you get what you were expecting!



A Product Backlog should be primarily based on organization-specific priorities. That means "must" should generally be higher than "should" or "could" items. However, frameworks like Scrum that are built around iteration goals provide latitude to include secondary objectives or stretch goals during iteration planning.

Understanding Backlog Collaboration in Scrum

A Product Backlog is required to be ordered. Anything that's optional or lower-priority should generally be kept below required features/functionality until such work comes into scope for other reasons such as a change in business priorities.

The Product Backlog may contain ancillary data about the agile release plan based on the expected lead time, but this in no way provides a guarantee or permits the Product Owner to define or control the contents of the Sprint Backlog.

The contents and format of the Product Backlog are up to the Product Owner. There's no framework requirement to carry estimates on the Product Backlog, but teams that regularly do Backlog Refinement often store non-binding estimates there to aid in Sprint Planning and other forecasting activities. Likewise, only the Development Team can assign level-of-effort estimates to backlog items or pull work into a given Sprint Backlog.

The Product Owner never assigns work to a Sprint; instead, the Product Owner works with the rest of the Scrum Team to craft a Sprint Goal for each iteration that provides a central coherence for the work that can fit into the current time box. The Development Team then pulls work off the top of the Product Backlog during Sprint Planning, using the Sprint Goal as a filter. The Product Owner and the Development Team can work together to identify "should" and "could" items that relate to the Sprint Goal, and the Product Owner can prioritize such work on the fly during planning events when the team may have additional capacity.

Always remember that only the Product Owner can prioritize the Product Backlog, and only Development Team can pull work into a Sprint Backlog. While there is a formal separation of responsibility for the two backlogs, that doesn't mean the Product Owner and Development Team can't (or shouldn't) collaborate. The entire Scrum Team should be actively collaborating throughout the project life cycle, rather than tossing stuff over the wall to one another at Sprint boundaries.


MoSCoW is not typically a good way to prioritise a backlog. Firstly because it isn't fine-grained enough. Having just four fixed categories becomes insufficient as soon as the stories in any one category exceed the capacity of a sprint. Secondly, "absolute" categorisation like MoSCoW risks giving stakeholders and teams the wrong mindset. It may prompt some irrelevant discussion about what "must" or "should" be the case instead of focusing on what really matters, which is relative priority. I like to allocate priorities on a scale of 1 to 1000.

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.