I’ve never been a fan of MoSCoW prioritization. It involves sorting product backlog items (or requirements on a non-agile project) into those that a product
- Must Have
- Should Have
- Could Have
- Will Not Have
The first letters of those (MSCW) form the basis of the acronym. The premise is that must-have items are true requirements—include these or don’t bother building the product.
The product could be released with its should-have items but if too many are absent, the product will probably not be very satisfying.
And could-have items are ones our customers and users want, but they acknowledge they’re of lower value than the should-haves and must-haves.
It’s possible to think of the must-haves as analogous to a minimum viable product. The should-haves and could-haves then move a product from viable to delightful.
What I Dislike about MoSCoW
There are a couple of things I dislike about the MoSCoW technique. First is that I can’t recall a project ever including any could-have features. A feature on the could-have list might as well be put on the Will-Not-Have list.
This is why I’ve written previously about preferring a simple approach of Now and Not Now. Are we building a particular feature Now? Or Not Now?
Needs, Wants, and Wishes
A few months ago, I came across a different technique that is similar to MoSCoW. And I liked it.
Once a year, I meet with a financial planner who reviews my investment accounts and tells me if I’m on track toward things like retirement. (I’m not retiring any time soon—I love what I do far too much for that.)
Since my previous meeting with the planner, she’s begun using new software. And to prepare for our meeting she asked me to log into it and fill out a few pages of information.
One of those pages asked me to enter my needs, wants, and desires. At first I thought “needs, wants, and desires” was an old song from either Dusty Springfield or John Denver.
I clicked on a little question mark icon on the page to get some clarification. I read that Needs are things I will absolutely plan for in my future. Obviously that includes food, shelter, medical care, and such.
I also included in my retirement needs that my wife and I would like to visit our daughters, who may not live near us as they pursue their lives. Sure, maybe that’s a want instead of a need. But since this was a retirement planning effort, I was saying that I’d make the choice to work a little longer if that’s what it takes to be able to visit my daughters.
The software informed me that my wants were things I really, really wanted to plan on. But I’d be willing to give them up if necessary in order to make the plan work. I enjoy eating at restaurants so I wanted a retirement budget that supported that. But it’s something I want, not something I need.
Finally, the software wanted to know my wishes. There really wasn’t much definition other than they’re a notch below my wants. And I didn’t really have anything to put in that category—probably because of my view that Could-Haves never get delivered anyway. But, I was told, this is where I’d add things like taking a month-long cruise around Greece.
Finding It Helpful
Despite my dislike of Must-Have, Should-Have, and Could-Have, I found Needs, Wants, and Wishes quite useful.
I think it’s because of the clarity. I find must-have, should-have, and could-have to be unclear. The product must have these features or what? It must have these features according to whom?
I find the could-have list particularly troublesome. Just about everything I’ve ever wanted could be added to a could-have list. Building a new e-commerce website? It could have a feature to cook me breakfast every morning.
Thinking of the Needs, Wants, and Wishes of your users seems to get around these problems.
Since encountering the idea in the financial planning software, I’ve had the opportunity to try these categories out with three companies. In each case it went well, and I found explaining wants vs. wishes easier than explaining could-haves.
