Prioritizing Features with a Structured MVP-Scoping Method

Good to see you again. In the previous lesson, you identified who at Harborline can validate approved returns guidance, permitted access, agent usability, and business value. Those people will not necessarily want the same features first. A policy owner may ask for broader document coverage; agents may want a faster handoff; a sponsor may want evidence of saved time.

Today you will use MoSCoW prioritization to turn those requests into a defensible order for a specific pilot. The goal is not to label every desirable feature “essential.” It is to identify the smallest usable assistant Harborline could test safely, distinguish valuable additions from necessities, and leave room for uncertainty. That is a useful client-facing skill: a recommendation needs reasons, not just a ranked list.

Choose the timeframe before ranking the features

A feature has no meaningful MVP priority in isolation. “Support every returns document” might matter for an eventual rollout but be unnecessary for a pilot using one approved collection. Start by stating the decision the pilot is meant to support:

Proposed Harborline pilot: A defined group of returns agents uses an internal assistant to find answers in approved returns guidance. Agents can inspect the supporting source and follow the existing specialist route when the guidance does not support an answer. The pilot tests evidence-finding, agent effort, rework, and restricted-document disclosure.

This is a working scope, not a claim that Harborline has approved the sources or the pilot. The validators from the previous lesson still need to confirm those conditions.

MoSCoW assigns requirements to Must Have, Should Have, Could Have, or Won’t Have this time. The last category is especially important: it means “not in this timeframe,” not “never.” Watch ProductPlan’s short explanation for the vocabulary and the need to agree on criteria with stakeholders before assigning labels.

The governing question for a Must Have is: If this were absent just before the pilot, would we stop rather than run the pilot as defined? “It would be nice” is not enough. Nor does “the sponsor asked for it” establish that the pilot cannot work without it. An important feature with an acceptable temporary workaround can be a Should Have. A feature whose omission causes relatively little harm is a Could Have. A feature the team agrees not to pursue in this pilot is a Won’t Have this time.

For the fuller decision rules, read the Agile Business Consortium’s explanation. Its distinction between a truly unusable delivery and a painful-but-viable workaround will guide the Harborline example below.

Separate a necessary outcome from one particular implementation

Harborline’s earlier success criteria included no restricted-document disclosures in the agreed tests. That makes safe access a condition of the pilot; it does not automatically make a sophisticated, document-by-document permission system a Must Have.

Suppose the policy and security owners approve one current returns collection that every pilot agent is allowed to read. Harborline could restrict the assistant to that collection, exclude restricted documents entirely, and limit pilot access to the approved agent group. That may be a viable first approach if the relevant owners approve it and tests confirm the boundary. If the pilot instead needs documents with different permissions for different agents, that simpler approach is insufficient; the team must enforce those permissions before exposing the documents, or change the pilot scope.

The distinction is consequential:

• Must Have outcome: Pilot agents must not receive content they are unauthorized to see.
• Possible MVP implementation: Use only sources approved for every pilot agent, with access to the pilot itself controlled.
• Possible later implementation: Support multiple collections with differing document-level permissions.

A priority label cannot substitute for a security approval or a passing test. If Harborline cannot establish a safe source set, the team does not reclassify safety as “Should Have”; it changes the proposed pilot or does not launch it.

The same reasoning applies to unanswered questions. A prominent shortcut into a specialist queue might be useful, but agents could initially follow their existing route. The Must Have is that the assistant does not present an unsupported answer as approved guidance and clearly tells the agent to use that route when evidence is insufficient. The shortcut is a candidate Should Have, not necessarily a prerequisite.

Prioritize a candidate list for Harborline

A consultant should make each candidate small enough to judge. “Enterprise-ready knowledge assistant” is too broad: it hides the difference between a single approved source, a citation, a feedback button, and company-wide document access. The table below is an illustrative first pass, subject to Harborline’s owners and delivery team validating the assumptions. Effort estimates are rough team-person-days across the work needed to deliver and check each item, not promises.

These judgments are deliberately conditional. If representative agents cannot use the existing specialist route during the task, the handoff shortcut may need a higher priority—or the Must Have escalation requirement needs a different workable implementation. If a current source cannot reliably be withdrawn from the assistant, the source-maintenance estimate or design must change. Prioritization exposes these assumptions; it does not make them true.

Notice also that the table prioritizes delivery requirements, while the stakeholder map identifies validation authority. The policy owner must approve which sources are current. The security owner must accept the access approach and review its tests. Agents and operations staff must check whether the task and workaround actually work. Those approvals are conditions for the pilot, not optional features to trade away.

Check effort, dependencies, and flexibility

A common failure of MoSCoW is declaring almost everything a Must Have. That leaves no practical way to protect the date when estimates or assumptions prove wrong. The Agile Business Consortium recommends keeping Must Have work at typically no more than 60% of the effort planned for a timeframe, with a Could Have pool around 20%. These are planning heuristics, not safety thresholds or quotas to satisfy by inventing optional work.

In the illustrative Harborline table, the in-scope estimates total 22 team-person-days: 13 Must, 5 Should, and 4 Could. Must work is about $13/22\approx 59\%$; Could work is about $4/22\approx 18\%$. Won’t Have items are excluded from that calculation. A real team would revisit these rough numbers after investigating source quality, permissions, testing effort, and its actual capacity. The percentages do not prove that 13 days of Must work is deliverable.

Dependencies matter more than a tidy percentage. The cited-answer feature depends on approved sources. The proposed access approach depends on the included collection being appropriate for every pilot agent. A Must Have cannot rely on a Could Have that the team may drop. That is why the Must Have escalation behavior directs agents to an existing route; it does not depend on the Should Have handoff shortcut. Likewise, pilot feedback must still be obtainable if the Could Have in-app feedback button is omitted.

Read the Consortium’s guidance on balancing effort and decomposing oversized requirements. It also points out that priorities can change across a project, an increment, and a shorter timebox—which is why “Won’t this time” should not be mistaken for “never.”

There is a practical consequence when estimates change. If the approved collection turns out to contain conflicting versions, the team cannot quietly drop source validation to preserve a date. It could instead narrow the collection further, resolve the conflict with the policy owner, or postpone the pilot. If the handoff shortcut takes longer than expected, it can be omitted while keeping the existing specialist route. MoSCoW works when the team knows what can flex and what cannot.

Turn the ranking into a client decision

Before treating this first pass as an agreed plan, bring the table to the validators identified last lesson. For each proposed Must Have, ask whether they would actually stop the defined pilot if it were absent; for each Should Have, name the temporary workaround and who confirms it is usable. Have delivery staff estimate the full work, including source preparation and verification, not just coding. Record dependencies and revisit the labels if a requirement turns out to contain both essential and optional parts.

The resulting recommendation should say more than “build the four Musts first.” It should explain the pilot objective, the assumptions under which the Musts are sufficient, the conditions that block launch, the work that may flex, and who has authority to accept the trade-offs. That makes prioritization inspectable when a sponsor asks for another feature or new evidence changes the scope.

Conclusion

MoSCoW helps you prioritize a defined timeframe: Must Haves make Harborline’s pilot viable and acceptable; Should Haves add important value with a workable temporary alternative; Could Haves provide optional value and flexibility; Won’t Haves are explicitly outside this pilot. Test Must labels by asking what omission would do to the pilot, decompose broad requests, check dependencies, and use effort proportions as a warning about overcommitment—not as a substitute for evidence or approval.

Next lesson, you will turn this provisional ranking into a precise MVP boundary, including an explicit record of deferred capabilities.