Scope a web app MVP as one complete journey

Begin after the custom-app decision

This exercise starts when the team has already decided that a custom web app is the right direction. Name the problem that decision is meant to solve and the evidence still uncertain. “Staff cannot reliably see which accepted requests need an eligibility review” is a scope anchor. “Build a complete operations platform” is a destination with no release boundary. The first version should test the riskiest service assumption while completing a task someone actually needs.

Choose one primary user in one situation. Describe what they know when the journey begins and the observable result at the end. Then list the records, decisions and permissions required between those points. A feature belongs in the MVP because the journey fails without it, because it controls a material risk or because it supplies evidence needed to decide what to build next. Popularity in a workshop is not enough.

Complete the primary-user and journey worksheet

Write the worksheet as a short operational story, then confirm it with the people who perform and own the work. Keep “not decided” visible rather than allowing mockups to choose policy accidentally.

• Primary user: Which specific role uses the release, and what responsibility gives them permission to act?
• Starting condition: Which event or existing record makes the journey possible, and which system is authoritative?
• Core task: What information must the user review or enter, and which decisions remain human?
• Successful outcome: Which durable state proves the task finished, and who relies on that result next?
• Exceptions: Which missing, invalid, duplicate, unauthorized or unavailable states must the first release handle?
• Dependencies: Which identity, data, integration, policy or content decision could block the journey?
• Exclusions: Which related users, records, reports and conveniences are explicitly outside this release?

Make the release small and complete

A thin release contains screens but leaves the work unfinished. A bounded release may support only one request type, yet it includes authorization, validation, confirmation, correction and an operator path when something fails. Include the least functionality needed for a trustworthy end-to-end outcome. Defer secondary dashboards, broad configuration and convenience automation when the core task can be completed and observed without them.

Treat security and accessibility as qualities of the journey, not features placed in a later column. OWASP’s Application Security Verification Standard offers a basis for defining verifiable application controls. Select requirements proportionate to the app and data, including authentication, access control, validation and secure handling. Likewise, specify keyboard operation, labels, errors and status changes within the acceptance criteria for the screens that ship.

Hypothetical example: a request review MVP

Consider a hypothetical training provider that has chosen to build a small app for reviewing course-access requests. The primary user is an operations coordinator. The journey begins with a request already accepted from the website, lets the coordinator review eligibility answers and supporting evidence, then records approved, declined or needs-information with a reason. The requester receives a separate update through an existing communication process.

The MVP includes sign-in, a queue, one request view, role-based decisions, required reasons, an audit entry and a visible failed-notification state. It excludes self-service customer accounts, bulk decisions, custom reports and automatic eligibility scoring. Acceptance includes preventing a coordinator from deciding the same request twice and preserving the request when the notification service is unavailable. This is a hypothetical planning example, not a Kinetivy client result.

Pair acceptance criteria with exclusions

Write acceptance criteria from the user’s observable outcome. “Given an accepted request assigned to my team, when I choose needs-information and provide a reason, the request shows that state once and the action is recorded” is clearer than “build status dropdown.” Add criteria for unauthorized access, invalid input, repeated submission and dependency failure. These statements define what the first release must prove without turning this planning guide into a later test procedure.

Put exclusions beside the criteria, with a rationale and review trigger. “Bulk decisions are excluded until individual decision patterns are observed for one review cycle” gives the team a reason to revisit the idea. Avoid calling deferred work “phase two” when no evidence or owner will trigger it. GOV.UK’s service guidance treats alpha as a way to test risky assumptions and beta as building and improving a service for users; scope should preserve room to learn rather than imply the first list is final.

Use a now, next and later decision table

Review each feature against the primary journey, risk and learning goal. “Now” is committed release scope. “Next” has a plausible need but depends on evidence from the first release. “Later” is recorded without a delivery promise. Remove duplicates phrased at different levels, and separate business rules from interface ideas so a preferred screen does not conceal the actual requirement.

• Now: Required to complete the core journey, manage a material risk or collect the evidence the release is designed to learn from.
• Next: Useful after a named adoption, exception or operating pattern is observed, with an owner responsible for the decision.
• Later: A valid possibility that does not support the first journey or current learning goal.
• Excluded: Conflicts with the service boundary, creates unacceptable risk or belongs in an existing tool.
• Dependency: Cannot be scheduled until an external policy, integration, data or ownership question is resolved.
• For every Now item, record acceptance criteria, responsible owner and the journey step it enables.