MoSCoW Method for Solo Developers: Prioritize Without a Team

Key takeaways

• Must Have inflation is the primary failure mode when applying MoSCoW solo. Without a team to push back, every feature you planned feels essential.
• The workaround test is your main bias filter: if users could get by without a feature at launch, it's at most a Should Have.
• Set your timebox before you categorize anything. Without a deadline, the four categories are meaningless.
• Keep Must Haves under 60% of your available capacity. If you're over that threshold, you haven't prioritized. You've just renamed your full backlog.
• When MoSCoW feels like too much overhead for a tiny project, an ordered backlog with effort labels is a legitimate alternative.

MoSCoW was built for room-sized disagreements. When everyone argues about what's "essential," forced negotiation makes people honest. Solo, that safeguard disappears. You're negotiating with yourself, which means every feature tends to feel like a Must Have by default. The method still works, but you need to run it differently.

Why MoSCoW was designed for teams (and what that means solo)

The framework was created to resolve disagreements between stakeholders, not to help one person sort a to-do list.

Dai Clegg developed MoSCoW at Oracle in 1994 for rapid application development, and DSDM adopted it formally in 2002 as a core prioritization technique for timeboxed delivery. The full name gives it away: MUST = Minimum Usable SubseT. The test for a Must Have is brutal by design: "If this requirement is not met, the delivery is considered a failure."

That test works because it has to survive a room of skeptical stakeholders. When a product manager says "login is a Must Have," a developer can ask "would we actually cancel the launch if it was missing?" In a team, that question gets answered out loud, with friction. That friction is the whole point.

Solo, you answer that question in your own head. Heads are very good at finding reasons why the thing they want to build is absolutely critical.

The tool still applies to solo work. The DSDM handbook doesn't say "for teams only." But you need to understand what you're giving up when there's no room full of skeptics, so you can compensate for it deliberately.

What changes when you're the only stakeholder

Running MoSCoW solo is simpler in some ways and harder in others.

Simpler: you don't need dispute resolution. Nobody's going to argue about your app's login screen for 45 minutes. You don't need to get everyone on the same page, which is what Monday.com lists as MoSCoW's primary benefit. You can set your categories in an hour and start building.

Harder: your biases have no natural opponent. In team sessions, categories emerge from negotiation. Solo, they emerge from whatever you believe on a Tuesday afternoon. If you've been excited about a feature for two weeks, you'll find reasons to call it essential. The categorization exercise becomes a justification exercise.

The practical adjustment: treat yourself as two roles. When you're doing MoSCoW, you're the PM. You're not the person who built the feature or has strong feelings about it. The PM applies the tests objectively, sets the categories, and locks the list. Then the engineer executes.

Mixing those roles (categorizing and building in the same mental frame) is where solo MoSCoW breaks down. Decide with your PM hat. Build with your engineer hat. Don't do both at once.

How Must Have inflation happens solo

Every item in a solo backlog was put there for a reason.

You thought of it, planned it, maybe sketched out how it would work. By the time you're doing MoSCoW categorization, you've already invested some mental energy in each feature. That investment makes every item feel more important than it objectively is.

Must Have inflation isn't dishonesty. It's a natural result of having been the one who planned everything. In a team, the people who didn't plan a feature have no attachment to it. They can evaluate it cold. You can't.

The pattern looks like this: you sit down to categorize, apply the Must Have test ("would we cancel the launch without this?"), and you find that you'd cancel the launch without almost everything. Login system, profile page, core feature, dashboard, settings panel. They all feel like load-bearing walls.

If your Must Have list covers more than 60% of your estimated capacity, something has gone wrong. The DSDM handbook sets that threshold explicitly: Must Haves should not exceed roughly 60% of available time. The buffer exists to absorb Should Haves and the inevitable schedule overruns. If Must Haves fill 100% of your timebox, you have no flexibility when things take longer than expected. And things always take longer.

The workaround test: your main bias filter

The most practical tool for solo MoSCoW is a question, not a framework.

"Is there any workaround users could use if this feature wasn't there at launch?"

If the answer is yes, the feature is at most a Should Have. Users could get by. The launch doesn't fail. You should probably build it, but not this sprint.

If the answer is no, truly no workaround exists, you might have a Must Have. But then run the cancellation test: "Would I actually cancel the launch if this feature was missing?" Not "would it be worse." Cancel. Shut it down. Ship nothing.

When you apply both tests in sequence, most things that felt like Must Haves don't pass. A habit-tracking app without streak tracking still works. Users can check in; it just lacks a motivation mechanic. That's a Should Have. Without check-in functionality, there's no app. That's a Must Have.

The tests work because they're concrete. The DSDM definition of Must Have uses the cancellation framing explicitly: failure condition, not "would be nice to have" condition. Asking "would I cancel?" forces an honest answer faster than any amount of general reflection.

How to set a solo timebox

Without a timebox, the four categories are decoration.

"Must Have" only means something relative to a deadline. Must Have by when? If the answer is "someday," you don't have a Must Have, you have a preference. The discipline of MoSCoW is that the deadline is fixed and scope is the variable. Flip that, and the whole framework loses its purpose.

Solo developers have three realistic timebox options.

A weekly sprint works well for projects you're shipping steadily. Each week, you pick what must ship by Friday. Short feedback loops, easy to adjust. Good for ongoing products where you're releasing incrementally.

A release milestone is a defined v1 or public launch. This is the most common solo use case. You pick a feature set for "v1.0 that I'd be okay showing people," and MoSCoW tells you what's in scope for that release. Good for side projects with a specific target.

A fixed calendar date applies when you have an external deadline: a conference, a client demo, a contract due date. The date is non-negotiable. MoSCoW becomes a triage tool under real pressure.

Pick one before you touch the categories. It doesn't need to be perfect. You can adjust the timebox later. But you can't categorize honestly without knowing what you're categorizing relative to.

How to run a solo MoSCoW session (step by step)

You don't need a meeting room. You need 30-60 minutes and a willingness to be honest with yourself.

1. Write out every feature, requirement, or task you're considering for this timebox. Everything. Don't filter yet.

2. Set the timebox. Weekly sprint? Release milestone? Fixed date? Decide now, before you look at the list.

3. Estimate rough capacity. How many hours do you have available? Don't be optimistic.

4. Apply the two tests to each item: the workaround test and the cancellation test. Write Must/Should/Could/Won't next to each item. Do this quickly. Don't overthink individual items.

5. Count your Must Haves against your capacity. If they exceed 60%, go back and reapply the cancellation test more strictly. Some of those must-haves are should-haves that felt important in the moment.

6. Record Won't Haves explicitly. Don't delete them or leave them in a vague "backlog." Write them down as Won't Have This Timebox. This prevents them from quietly sliding back in during a late-night coding session. The DSDM handbook requires recording these; solo developers often skip this step and then wonder why scope keeps growing.

7. Lock the list. Switch to engineer mode. Stop questioning the categories until the timebox ends.

MoSCoW in practice: solo habit tracker example

Here's what a real categorization looks like for a solo developer building a habit-tracking app with a 4-week timebox.

Starting feature list:

• Daily check-in UI
• Streak tracking
• Push notifications
• Social sharing / public profile
• Data export (CSV)
• Onboarding flow
• Dark mode
• In-app analytics dashboard

Applying the workaround test and cancellation test to each:

Daily check-in UI: no workaround. Without this, the app does nothing. Cancel without it? Yes. Must Have.

Onboarding flow: workaround exists (user can figure it out, or you can document it externally). Cancel without it? No. Should Have.

Streak tracking: workaround exists (user can track manually). Cancel without it? No. Should Have.

Push notifications: workaround is manual habit-checking. Cancel without it? No. Could Have.

Data export: clear workaround (screenshots, manual notes). Cancel without it? No. Could Have.

Social sharing: obvious workaround (just don't share). Cancel without it? No. Won't Have this release.

Dark mode: workaround is system-level dark mode if supported. Cancel without it? No. Won't Have this release.

In-app analytics: no user-facing need in v1. Won't Have.

Result: 1 Must Have, 2 Should Haves, 2 Could Haves, 3 Won't Haves. That's a reasonable v1 scope.

Without the tests, the most common solo outcome is 5-6 Must Haves, a couple of Should Haves, and nothing in Won't Have. Then the timebox blows past because "everything was essential."

When MoSCoW isn't the right tool for solo work

MoSCoW has real limits, and recognizing them saves you time.

No deadline means no timebox means no reason to choose. If you don't have a timebox, you don't have a prioritization problem. You have a goal-setting problem. Solve that first. MoSCoW won't help you decide what to build when you're building indefinitely.

Creative or exploratory work is a poor fit. MoSCoW is a scope management tool. It works when you have a defined set of requirements and need to decide what fits in a box. When you're prototyping or exploring an idea with no defined deliverable, you're not scoping. You're discovering. An ordered backlog or just a blank file works better.

Persistent self-deception breaks the tool. If you apply the cancellation test and keep finding that yes, you would genuinely cancel the launch without feature X, Y, and Z (all of which happen to be features you're excited about), the test isn't working. The tool requires honest application to produce useful output. If you can't apply it honestly, the output is garbage.

For solo developers who want objective numbers, RICE scoring (Reach, Impact, Confidence, Effort) gives you a ranked list with a defensible numeric score. It takes longer than MoSCoW, but it produces something you can challenge yourself on. For very small scopes, a simple ordered backlog with effort labels ("high/medium/low effort, high/medium/low value") does the job without the MoSCoW overhead. If you're using AI tools in your workflow, a structured PRD template for AI coding tools can help you define requirements clearly before you prioritize them.

Key terms

MoSCoW method is a prioritization framework developed by Dai Clegg for timeboxed delivery, where requirements are categorized as Must Have, Should Have, Could Have, or Won't Have to define scope relative to a fixed deadline. Wikipedia

Must Have (MUST = Minimum Usable SubseT) is the MoSCoW category for requirements without which a delivery is considered a failure. The test is binary: would the team (or solo developer) cancel the release if this was missing? DSDM Handbook

Timebox is a fixed, non-negotiable time period within which delivery must occur. In MoSCoW, the timebox is the constraint that makes prioritization meaningful. Scope adjusts to fit the time, not the other way around.

Should Have is the MoSCoW category for requirements that are important but not vital, where a workaround exists. They're included if capacity allows and dropped first if the timebox is at risk. DSDM Handbook

FAQ

Does the MoSCoW method work for solo developers?

Yes, but solo use requires deliberate adjustments. MoSCoW was designed as a negotiation tool for teams, so its main safeguard (people challenging each other's assumptions) isn't there when you're working alone. To make it work solo, you need to use the workaround test and cancellation test explicitly, set a real timebox before categorizing, and cap your Must Haves at 60% of available capacity. Without those adjustments, MoSCoW solo tends to produce a Must Have list that covers your entire backlog.

What's the biggest mistake solo developers make with MoSCoW prioritization?

Must Have inflation. When you planned every feature yourself, you have some attachment to all of them, which makes every item feel essential. The workaround test helps: ask "is there any workaround users could use if this wasn't there at launch?" If yes, it's at most a Should Have. The cancellation test is even stricter: "Would I actually cancel the launch if this was missing?" Most features don't survive both questions honestly applied.

How do I set a timebox for a solo side project?

Pick one of three options: a weekly sprint (good for incremental shipping), a release milestone (best for a defined v1 launch), or a fixed calendar date (when you have an external deadline). The specific choice matters less than making one before you start categorizing. MoSCoW's categories mean nothing without a deadline. "Must Have" only makes sense relative to a specific delivery moment.

When should a solo developer use RICE scoring instead of MoSCoW?

When you need objective numbers rather than categories. MoSCoW gives you buckets; RICE scoring (Reach, Impact, Confidence, Effort) gives you a ranked list with a defensible numeric score per feature. ProductPlan's explanation of RICE covers the scoring method. RICE takes longer to apply, but it's harder to game with self-deception. If you find yourself consistently inflating MoSCoW categories no matter what, switching to RICE forces more honest evaluation.

How is the MoSCoW method different for solo work versus team use?

The core categories and tests are identical. What changes is who applies them and what happens if the categorization is wrong. In a team, categorization is a negotiated output. Multiple people have to agree that a feature is a Must Have, and someone will push back on inflated claims. Solo, you're the only check on your own reasoning. Getting Must Have wrong in a team means stakeholder conflict and scope negotiation. Solo, it means you blow your timebox and your side project stalls.

Related resources

• MoSCoW Prioritization When Everything Feels Must-Have: the team and stakeholder context for MoSCoW, including how to run a session with others
• Solo Developer App Release Checklist: Step-by-Step: what to verify before shipping your solo project

Changelog