What to do when the client thinks EVERYTHING is a Must-Have

One of the guiding principles of agile workflows is ensuring that the most important things get done first. I always position this in terms of a worst-case scenario: that the project ends abruptly and whatever has been done thus far must be presented as the final product. Of course, in reality, this shouldn’t happen but it is good motivation to aid prioritisation nonetheless. In theory, the hierarchy of tasks is quite simple and laid out in the MoSCoW prioritisation framework.

Photo by airfocus on Unsplash

What is MoSCoW?

MoSCoW stands for, Must Have, Should Have, Could Have and Won’t Have (sometimes “Would Have” is used, as in “if we have time we would do this as well”). Once user stories have been created, the project leader and the client agree on which stories MUST be included in the product release. These stories are critical to product success and without them, it is impossible to achieve the success criteria. They should also be central to delivering the value proposition and not merely facilitatory. If only the M is complete, the product will be what is commonly called the MVP (minimum viable product).

“Should have” stories are the next priority and either facilitate a “Must Have” story, or increase the value, usability or ease of use for the product. These are not critical to the product meeting the success criteria but make it easier to use and elevate the offering to a minimum marketable product (MMP). Conventional wisdom suggests that MVP features should be validated in a real market (a small, loyal one) before introducing features that should be in the product.

“Could have” features usually come about when the sentence starts with “it would be cool if…” or something similar. These stories certainly add flavour to whatever the project team is cooking but may have minimal impact on converting new users, when included in an immature product. These stories should be relegated to a later release, where they may be revisited once customers have had a chance to use the product. You may want to create some market research around some of these before you include them in a product build or even earmark them in case enough customers start to request a similar type of thing.

Finally, “Won’t Have” stories, have been identified and written up but are either such a low-priority or so far removed from the hypothesised solution that they are unlikely to ever make the cut to be in the product. My experience tells me to keep these somewhere (maybe even in your backlog) as a reference point in case they reemerge.

Pretty straightforward, right? However, I have probably worked with 2 clients that have been able to put this into practice. And these aren’t bad clients or with fractured decision-making units like I spoke about here. But what usually happens is, 85%+ of the stories are considered to be “Must Haves”. And this isn’t through lack of trying. Once we go through the ideation stage and create stories based on the proposed solution, it is often difficult to put the toothpaste back in the tube. Once the idea has been spoken about, the client can already envision it as part of the product and you are fighting an uphill battle to get it removed from the “critical” category. Effective ideation will always produce some stories that are not critical. It is the only way that you can make sure you cover all critical aspects. So trying to only write must-have stories is also the wrong move.

And this will only get worse. Continuous discovery dictates that once you have completed the initial discovery phase, the elements identified during discovery continue to be iterated during implementation. This is especially pertinent to prioritisation as feedback from customers, new ideas from the client and other inputs will continuously create new stories. You need to find a consistent and objective way of prioritising them against each other and existing stories.

Introducing the Weighted Prioritisation Matrix

One method I have found very effective in prioritising and moving clients away from the idea that everything is critical, is to create a weighted prioritisation matrix. I talk about this in the Discovery Section of my Strategic Projects Mastery Playbook and I have used this in countless product discoveries, continuing into implementation.

How does it work?

When weighting a matrix, unless you have information to tell you otherwise there are a number of arbitrary inputs. Provided they are applied with consistency, they do not negatively affect the outcome. The goal of the matrix is to provide each story with a score to prioritise it against other stories and an arbitrary threshold that all stories need to meet to be included in the release. The matrix has four categories, each with a different level of importance/weight, which will vary from company to company and depending on their product maturity phase. The categories are:

1. How much is the feature needed to meet a basic user requirement?
2. How much is the feature a market differentiator or creates a “wow” factor?
3. How much does the feature impact the long-term strategic position of the company?
4. How much does the feature improve the customer experience?

Each story then receives a score from 0 to 10 (10 being the highest) based on how well that story satisfies the criteria for that category. All stories should be scored in all 4 categories (even if three are 0/10). Some degree of subjectivity will naturally come into play. For instance, what is the difference between a 6 and a 7? In any case, provided common sense is applied the result will be roughly the same. Now comes the weighting of the categories. This should score the categories in relative importance to each other. For instance, when building a flagship product at a startup, I use:

• x2 for category one
• x1 for category two
• x0.5 for category three
• x0.75 for category four.

This means that meeting the basic criteria is twice as important as having market differentiators and four times as important as working on the long-term strategic position. That might sound contrary to my general philosophy (ensuring strategic alignment between all projects and company objectives) but remember all categories should receive a score for all stories. So a story that scores highly for meeting basic user requirements is likely to score highly for long-term strategic positioning, but the reverse may not be true.

Now every score you previously input will have a multiplier to increase or decrease it’s significance. Sum the scores and that is the ranking for that story. Using the ratios suggested, a total score of 20 or more should make the grade to be included in the release. Stories between 17 and 23 will form the majority of the discussion but at least you can objectively compare them to each other and the threshold of 20. With this scoring system, the client can no longer decide that everything is a must-have in the current release and is forced to make choices against objective criteria.

And after discovery?

This framework continues to be valuable once you enter the implementation phase. Anything new that comes into the backlog can immediately be scored using the same criteria. If it scores below a 20 then it immediately falls below the required threshold. If it scores above 20 then you can directly compare to other stories of similar scores and decide whether there is a necessary increase to the scope, something should be replaced or postponed.

Conclusion

Maintaining objectivity is crucially important when prioritising stories so finding a way to remove the urge to include every good idea in a release is a worthwhile task. The time used during discovery, building and executing this framework, will be rewarded with a streamlined product release, aligned with the core success criteria and company goals. It also provides a near-irrefutable method to align the client with the real must-haves and challenges any preconceived ideas about any stories that fall below the threshold.