Defining the MVP Boundary and Deferred Capabilities

Good to see you again. Last lesson, you used MoSCoW to rank features for Harborline’s proposed returns-guidance pilot. The essential distinction was between an outcome the pilot cannot safely do without—such as preventing unauthorized disclosure—and one particular way of achieving it, such as a system that handles different permissions on every document.

A priority list is not yet a scope agreement. A client also needs to know exactly what the pilot will do, for whom, with which information, and what will not be delivered. In this final lesson of the module, you will turn the provisional ranking into an MVP boundary and a record of deferred capabilities. These are working documents for Harborline’s validators to review, not claims that they have already approved the pilot.

Define the smallest pilot that can answer the question

The point of Harborline’s MVP is not to demonstrate every possible knowledge-assistant feature. It is to learn whether a defined group of returns agents can find approved guidance more effectively through an internal assistant without losing the ability to check the source or exposing restricted material.

Rob Walling’s explanation of an MVP is useful here because it begins with what the team needs to learn, rather than with a feature catalogue. His examples come from products sold to customers; for an enterprise pilot, keep the principle of small scope, but do not treat security or source approval as shortcuts.

For this pilot, the question is narrow: Can eligible agents use an answer grounded in approved returns guidance to complete their evidence-finding task, while recognizing when they need to consult a specialist? That question determines what belongs inside the boundary. A multilingual experience might be valuable in a future rollout, but unless the defined pilot group needs it to perform the test, building it now would not help answer this question.

Minimum does not mean “fewest features regardless of consequences.” A pilot that returns plausible answers without inspectable sources might be small, but it would not adequately test trustworthy guidance. A pilot that inadvertently exposes restricted documents would not be acceptable to run. The boundary must therefore describe a viable and permissible test, not merely a short development list.

Write the boundary as a scope statement

A useful scope statement lets a reader determine whether a proposed task belongs to the pilot without relying on the team’s memory. It covers the intended users and workflow, included information, delivered behaviors, exclusions, constraints, and conditions for acceptance. Atlassian’s How to Define & Write a Project Scope shows how explicit exclusions sit alongside deliverables and constraints.

Here is a draft Harborline MVP scope record. It translates the previous lesson’s Must Haves into an observable pilot, while leaving matters that require client validation visibly unresolved.

Harborline returns-guidance assistant — pilot scope, draft

Purpose and decision: Test whether an internal assistant helps a defined group of returns agents find and check approved guidance for their work. Compare the pilot with the current workflow using the business and user-experience measures agreed earlier; verify the agreed safety conditions before use.

Users and workflow: Only eligible pilot agents ask returns-guidance questions in an internal agent-facing interface. They use the answer to inform their work; the assistant does not communicate with customers or make returns decisions for them.

Included information: One current returns-guidance collection, selected by the policy owner and approved for every pilot agent. A process must exist to replace or withdraw an outdated included source. Other collections are not available to the assistant in this pilot.

Included behavior: For a question supported by the approved collection, provide a concise answer with an inspectable citation to its source. When the approved evidence is insufficient, say so and direct the agent to the existing specialist route rather than presenting an unsupported answer as approved guidance.

Access boundary: Limit use to the eligible pilot group and exclude material they are not all authorized to read. The proposed single-collection approach is acceptable only if the security and source owners approve it and the agreed tests confirm the boundary.

Acceptance conditions: The cited-answer and insufficient-evidence behaviors work in representative agent tasks; citations can be checked against the included guidance; the agreed restricted-document tests show no disclosures; and the team can collect the previously defined evidence on agent effort and rework. The relevant owners and pilot stakeholders must review the results against the agreed criteria before a launch decision.

Not committed in the MVP: A direct specialist-queue shortcut, in-assistant change notifications, one-click feedback, recent-search shortcuts, other departments’ knowledge, sources with differing agent permissions, and a multilingual experience. Their differing dispositions are recorded below.

The record intentionally says “defined group” rather than inventing a headcount, and “agreed tests” rather than claiming a test suite has passed. Before it becomes an approved scope, Harborline must name the eligible group, confirm the source collection and existing specialist route, specify the measurement plan, and obtain the appropriate decisions. A draft should expose these gaps instead of concealing them behind precise-sounding guesses.

Notice how the access boundary narrows the pilot. It does not declare document-level authorization unnecessary in general. If Harborline needs to include sources that different agents have different rights to read, the proposed common-source boundary no longer holds. The team must change the design and validate it, or keep those sources outside the pilot.

Keep the commitment separate from the stretch work

The previous lesson called the handoff shortcut and change notifications Should Haves, and in-assistant feedback and recent searches Could Haves. Those labels mean they may be worth delivering if capacity permits; they do not make them part of the minimum pilot the team promises to deliver.

This yields two useful layers of scope:

1. Committed MVP baseline: The included behaviors and safeguards in the draft scope record. If one cannot be delivered and verified, the pilot as defined cannot proceed.
2. Conditional additions: Should and Could Haves that might be added only after the baseline is protected, their dependencies are checked, and the client agrees to the change. The pilot can still proceed without them if its stated workarounds remain viable.

By contrast, the previous lesson’s Won’t Have this time items—other departments’ knowledge and a multilingual experience—are excluded from this pilot plan. They should not quietly enter as “stretch work.” Adding them would require a deliberate scope decision.

The supplied story-map image makes the distinction between a near-term slice and later possibilities visible:

A release row is a helpful communication device, not an approval by itself. In Harborline’s case, the baseline needs an accompanying statement of approved sources, permitted users, acceptance conditions, and exclusions. Equally, placing an idea in a later row should not be read as a promise that it will be funded or delivered on a particular date.

Record deferrals so they cannot drift back unnoticed

An exclusion list names what is absent. A deferral record goes further: it explains why the capability is absent, what happens without it, and what evidence would justify revisiting it. That helps a sponsor distinguish a conscious trade-off from a forgotten requirement.

The Agile Business Consortium’s MoSCoW guidance, read in the previous lesson, recommends recording “Won’t Have this time” requirements precisely so they do not get informally reintroduced. The same discipline helps with Should and Could Haves that are outside the committed baseline.

These revisit conditions are signals to make a new decision, not automatic promises to build the features. The named validators from the previous lesson should check the relevant workarounds: agents and operations for the specialist route, the policy owner for guidance changes, and the security owner for any expansion of source access.

A deferral is legitimate only if its workaround preserves the pilot’s essential outcome. For example, the direct handoff shortcut can be deferred if agents can actually use the existing specialist route. The assistant’s obligation to acknowledge insufficient evidence cannot be deferred with it. Similarly, an automated change notice can be deferred only if included guidance can still be kept current and agents have an acceptable way to learn about changes.

Decide what happens when the boundary is challenged

A scope record is most useful when new information arrives. Imagine Harborline discovers that the proposed returns collection contains documents that only some pilot agents may read. This is not an invitation to move “no unauthorized disclosure” out of the Must Have category. It invalidates an assumption behind the proposed boundary. The team could narrow the collection to material approved for everyone in the group, redefine the pilot group with approval, or design and validate a different access approach. Until an acceptable route is established, it should not run the pilot as drafted.

A request for multilingual support is different. It may be valuable, but the team should first ask whether the defined pilot group and decision require it. If not, record the request against the deferral and leave the baseline intact. If representative agents cannot participate without it, the team must revisit the pilot group, objective, effort, and approvals—not merely append a feature to the list.

For each proposed change, use a short decision trail:

1. Identify the boundary affected: users, sources, behavior, access, measurement, or an explicit exclusion.
2. Test the effect on viability: Does the pilot still answer its question safely if the request is declined? Does an existing workaround actually work?
3. Assess the change: Estimate delivery and verification effort, dependencies, risks, and effects on the pilot’s measures.
4. Seek the right decisions: Ask the source, security, agent or operations, and business validators whose responsibilities are affected.
5. Update the record: Revise the scope, deferral, assumptions, and acceptance conditions together, with the decision and its owner visible.

This prevents a common mismatch: a feature is added to a delivery list while its source permissions, testing obligations, or client expectations remain unchanged on paper.

Conclusion

An MVP boundary turns a priority ranking into a precise proposition: these users will test this workflow, using these approved sources and essential behaviors, under these acceptance conditions. The companion deferral record states what is not promised, why it can wait, how the pilot operates without it, and what would justify another decision. For Harborline, both documents remain conditional until the source, access, workflow, and measurement assumptions are validated.

That completes the course’s framing module. Next, you will begin designing the GenAI solution by inventorying the enterprise knowledge sources that could support the pilot—starting with their formats, sensitivity, ownership, and update frequency.