Backlog Grooming

Question

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.

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.

Answer 1

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.

Answer 2

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.

Answer 3

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!

Answer 4

TL;DR

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.

Answer 5

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.