Schedule a Call

Choose a time that works for you.

Loading calendar…

If it does not load, Open Calendly directly.

Quote card for Needs, Wants, and Wishes on Your Product Backlog.

Needs, Wants, and Wishes on Your Product Backlog

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.

Explore Further

Article artwork for 5 Key Factors for Effective Product Backlog Prioritization.
Article

5 Key Factors for Effective Product Backlog Prioritization

Featured

Confused about how to prioritize your backlog? These 5 factors will help to focus your efforts.

Text graphic: Choose backlog items that teach and deliver.
Article

Choose Backlog Items That Serve Two Purposes

Featured

Choose backlog items that deliver value while helping the team learn what matters next.

Article artwork for Product Backlog Refinement.
Article

Product Backlog Refinement

Featured

Learn about product backlog refinement: how, when, and why the agile team and product owner refine the product backlog in Scrum.

Cyclist tries to avoid urgent detours en route to goal
Article

How to Ensure You're Working on the Most Important Items Each Iteration

Keep urgent work from crowding out the goals that matter most.

Article artwork for Four Steps to Keep Your Product Backlog Small and Manageable.
Article

Four Steps to Keep Your Product Backlog Small and Manageable

Reduce clutter so the backlog stays useful for prioritization and product decisions.

Article artwork for Why Your Product Backlog Should Look Like an Iceberg.
Article

Why Your Product Backlog Should Look Like an Iceberg

Shape the backlog so near-term items are detailed and lower-priority work stays lighter.