MoSCoW

Some projects have their launch date set before anything else. A contract names a day, or a conference does. The failure these schedules produce is rarely that the team couldn't build something. It's that in the final two weeks, nobody can agree on what to drop.

The moment someone proposes cutting scope, the conversation stalls in the same place. Sales says a deal depends on that feature. Engineering says pulling it now means restructuring. Design says the screen is half a screen without it. None of them is wrong. The problem is that the ranking is being attempted for the first time with the deadline in sight, and at that point nobody can afford to concede.

Scoring methods don't help much here either. Something like RICE, which multiplies reach, impact, and confidence and divides by effort, will line every candidate up from first to last. But the question isn't the order, it's the line. Whether the cut falls after item seven or item twelve is not something a score answers. MoSCoW draws the line instead of the queue. It was codified in 1994 inside a software development methodology built on one assumption: the date is fixed and the scope is what moves.

The name is the initials of four grades. The lowercase letters are there to make it pronounceable and carry no meaning.

1. Must have — without it, what ships cannot be called a release. The test is consequence, not preference: would shipping without it break the law, break the product, or break a signed commitment?
2. Should have — painful to omit, but the release survives. There is usually a workaround. The job still gets done, just by an operations person doing it by hand.
3. Could have — nice, and nobody grieves much if it's gone. This is the first tier to get cut when the schedule slips, and being cuttable is what it's for.
4. Won't have — explicitly not this time. It doesn't mean the item was never discussed; it means it was discussed and dropped. This grade is the one most often skipped, and skipping it is what makes the whole method go slack.

The run itself has four steps.

1. Pull the candidates out of the product backlog into one list and even out their sizes. A three-day item and a three-month item on the same table will scramble the grades.
2. Grade them with product, engineering, and sales in the same room. Grades assigned alone get disputed later.
3. Measure how much of the schedule the must-haves consume. The threshold is 60 percent. On an eight-week project, the must-haves need to fit inside five weeks.
4. Fill the remaining 40 percent with should-haves and then could-haves. That stretch is not a plan; it's the slack.

Step 3 is arguably the entire method. Let must-haves fill all eight weeks and you have a plan in which nothing is allowed to run late — and one incident in week one takes it down. The 40 percent isn't generosity toward the team; it's the room the schedule needs to absorb the things nobody listed.

The fit is specific: a fixed date with adjustable scope. Delivery promised to an enterprise customer on March 1, or a page that opens the morning of an event. What the team needs then isn't to know which feature ranks third. It's to know what can be cut tonight.

The mismatches are just as specific.

Don't use it for continuous development with no fixed date. Nothing forces a cut, so the grades stop meaning anything and every item drifts upward into must over time. Work like that is better served by something like a value-effort matrix, which places candidates on a quadrant of value against effort.

It also doesn't fit when you need fine-grained ordering. Within a grade there is no sequence. If twelve items sit in should-have, MoSCoW has nothing to say about which one goes first. When that answer matters, run something like ICE — scoring impact, confidence, and ease and multiplying them — inside the grade.

The sharpest limitation is how easily the grades turn into a negotiating position. A table where must-have exceeds half is not a prioritization; it's a wish list with a new label. The only defense is a number written down in advance: if must-have passes 60 percent, the grading is redone — and then actually sending it back when it does.

"Must-have is 70 percent of this sprint. We need to regrade."

There is no slack left, so the plan doesn't hold together.

"Let's put that in won't-have and revisit next quarter."

A promise to drop it without losing it.

"If only the must-haves ship, can the customer actually use it?"

A check on whether the grading was honest.

Pagedeck used this on its first enterprise contract, with delivery promised for March 1. Thirty-one requirements, seven weeks left. Mia booked a three-hour session and put Sofia from sales and Theo from engineering in the same room.

The first pass produced nineteen must-haves. Theo sized them at more than six weeks, so by the rule they went back and regraded. The second pass brought must-have down to nine. Admin permission settings stayed a must. The usage dashboard dropped to should-have because it wasn't in the contract. Recoloring the interface to match the customer's brand went into won't-have. An incident hit in the last week of February, and what got cut were three should-have items.

Nothing about that final week was a negotiation. The three items had been labeled cuttable seven weeks earlier by the same people who would have argued for them, which is the whole reason the cut took ten minutes instead of a day.

The most common misreading treats the four grades as a ranking of importance, with must at the top and won't at the bottom. They actually sort by necessity within this deadline, not by importance. The single most important feature for the company's long-term direction can legitimately land in won't-have this quarter. Read as importance, putting something in won't-have starts to feel like an insult to it, and people stop putting anything there at all.

The other misreading is that grading happens once. Grades move during the project. Something graded must turns out to be survivable once it's built, and occasionally the reverse. The difference between a team that revisits the table weekly and one that carries the first meeting's output to the end shows up in the final week, when the second team is deciding what to cut using two-month-old information.