Product Backlog Ordering - Beyond MoSCoW

The only reason for a Product Owner to exist is to maximize the value of the Product. One of the ways a Product Owner can accomplish this is by ensuring that most valuable items remain at the top of the Product Backlog and the Product Goal underscores their importance. So, how does the Product Owner order the Product Backlog; what techniques can be used? Is MoSCoW a valuable approach? Let’s explore.

Product Backlog organization and factors to consider

Scrum Teams thrive on adaptability and value-driven delivery. A cornerstone of this approach is the effective ordering of work items, which typically is done by the Product Owner. If you have ever taken one of Scrum.org's open assessments you might have encountered the question - how does the Product Owner order the backlog? The answer to this question is - however the Product Owner deems right. But is it so? Definitely not. Product Owners do not make reckless decisions. They are accountable for the success or failure of the Product. The aforementioned answer is however to establish that the final decision of what goes on to the Product Backlog and gets built into the Product is the Product Owner’s choice.

So what factors influence the decision making

There can be many factors that contribute to the ordering of the Product Backlog. A few could be tangible while others not so much. Some of these factors which are widely used include:

• Value: What value is being created or added by building a requirement into the product? To determine value the Product Owner may consider increase in customer satisfaction or market share; improved cost savings or revenue or any other metrics.
• Effort: The next factor that is usually considered is effort. How long will it take to build a requirement into a working software? Often this will be impacted by availability or resources, people, complexity and uncertainty of work items.
• Risk: The third factor is Risk. What happens if this requirement is not built into the product? Are there any potential negative impacts or uncertainties associated with a work item? A risk may further be classified as technical, functional and even reputational. For example: if GDPR compliance is not met, the product could not be launched in the European market and it can impact the brand value.
• Dependencies: Is there a workflow which needs to be followed? Is there a work item that needs to be done before the others? Is there a third-party dependency that needs to be resolved before picking an item? There could be many such aspects which might need to be addressed before deciding the order of the work items.
• Time Sensitivity: Is the work item time-critical? What if we don’t do it now? Can this be delayed till the next release? Would we end-up paying a penalty if this is not delivered? Answers to these questions often help in deciding the order.
• Strategic Alignment: How well a work item aligns with the organization's overall strategy and long-term goals.
• User Impact: The potential impact on the end-user experience. Ordering tasks that enhance user satisfaction can lead to increased adoption and loyalty.
• Priority: Priority or importance or preference of work items compared to each other. For example: if we need to send an OTP what should we prioritize - OTP to SMS or OTP to Email.

Is MoSCoW a helpful technique

The MoSCoW (Must Have, Should Have, Could Have, Won't Have) has been a popular mechanism for prioritization from traditional management days. It works well if people are willing to do it in the right way i.e. they are really considering work items that they won’t have on the backlog. IMHO, I have not seen any customer/client/stakeholder who would say that they won’t have a requirement on a Product Backlog. Rather, most stakeholders state everything on the backlog is a Must Have and should have been delivered “yesterday”.

There are some additional limitations of MoSCoW

• Bias: Different stakeholders may have different expectations and experiences leading to inherent bias and subjectivity about their own “Must Haves” or “Won’t Haves”.
• Rigid Mechanism: Since MoSCoW is often based on “HiPPO” interventions, once decided it does not allow flexibility to change the backlog as needs evolve over a period of time.
• Neglects Interdependencies: The dependencies across work items or with third parties is often neglected as MoSCoW mostly depends on opinionated biases.
• Limited Stakeholder Engagement: MoSCoW can be driven by a few key decision-makers, potentially excluding valuable input from other stakeholders.

Considering the above challenges, MoSCoW is not always the best approach to organize and order the Product Backlog.

Backlog Ordering beyond MoSCoW

Here are some more engaging ordering techniques that enable collective ownership and decision making. Following techniques enable the Product Owner to work collaboratively with key stakeholders and factor their ideas and opinions into Product Backlog ordering.

• Buy A Feature: This approach is based on the game of monopoly or business. The idea is stakeholders have a limited currency and they need to purchase the requirements that they desire in the Product. This technique is from Innovation Games by Luke Hohmann.
• Start Your Day: This is another great idea from the book Innovation Games. I do not use this idea as is for Backlog Ordering. Instead, I do a variation. I prefer to ask stakeholders to consider from the backlog all the items that they would like to be part of the Product if the next release was 6 months away. Then ask, what would they need to have if the release was 3 months away from the list that was identified earlier and finally, if we need to make the release this month which functions would they prefer to be part of the product.
• Kano Model: Kano model helps establish categories of various requirements like “Basic”, “Performance” and “Delighters”. Combining this with “Buy a Feature” mentioned earlier gives the Product Backlog a balanced order where functional as well as non-functional requirements can be addressed.
• Story Mapping: Another good approach to order and organize the Product Backlog could be with the help of User Story Mapping. User Story Mapping enables the Scrum Team and Stakeholders to dive deeper into the desired requirements and as they create requirements, boundaries can be established about what can be achieved in a quarter or two quarters. This can give a good organized Product Backlog. However, remember that these requirements are a forecast and the Product Backlog needs to be revisited frequently to keep it valuable.
• Dot Voting: Another easy to use technique to organize and order the Product Backlog is Dot Voting. The Product Owner may present a set of identified requirements and then allows stakeholders/customers to vote for their desired features/requirements. A stakeholder may have 3-5 votes and these votes can either be given to one requirement or distributed across multiple requirements. The requirement that receives the highest votes comes at the top of the Product Backlog while the one which receives the least comes at the bottom.

Conclusion

A well managed Product Backlog is essential for the success of a Product and creating value for its users as well as stakeholders. By knowing and applying the factors that might impact ordering; plus leveraging various techniques to organize the Product Backlog, a Product Owner may create a Product that engages the user and satisfies the needs of the stakeholders. 

I hope this article helps. If you find it useful then share and let me know your thoughts in the comments. Also, if you use any other techniques to order the product backlog do let me know.