Key takeaways
- Describe observable behaviour for each critical journey.
- Include failure and recovery paths in the first release.
- Separate launch requirements from later product ideas.
“Customers should be able to book online.” Everyone in the room nods. A few weeks later, the booking screen is ready, but nobody has agreed what happens when two customers choose the same appointment. The feature sounded clear because each person supplied their own missing details.
MVP acceptance criteria make those details visible before the team builds them. They describe what a customer or staff member should be able to observe, so “finished” means something more useful than a screen looking complete.
Start with what you want to learn
A first release should help answer a product question. For an appointment service, that might be whether customers will book without calling reception. The essential journey is choosing a service, seeing available times, entering details, confirming, and receiving a booking reference.
That gives the team a reason to include some features and defer others. A loyalty scheme may be interesting, but it probably does not help test that first question. Clear scope feels much less arbitrary when everyone understands the learning behind it.
Write one scenario you could demonstrate
Try this: “Given an available appointment, when a customer submits valid details and confirms, one booking is created, a reference is displayed, and reception can see it in the schedule.” A reviewer can walk through that. They can also point out what is missing.
Notice that the staff view is part of the result. A confirmation that never reaches reception is a broken booking, even if the customer’s screen looks correct. This is why acceptance discussions need people who understand the operation as well as the interface.
| Situation | Expected behaviour |
|---|---|
| Two customers choose the last slot | Only one booking is confirmed; the other customer is offered a next step. |
| Confirmation email is delayed | The booking reference remains available on screen. |
| A required field is missing | The form explains what to fix without losing valid entries. |
| The customer retries after a timeout | The service avoids creating a duplicate booking. |
Make the core journey usable
Include the conditions your actual audience needs: keyboard access, readable labels, understandable errors, and layouts that work on their phones. These are often treated as finishing touches, but they determine whether someone can complete the task you are trying to test.
You do not need a giant requirements document. A shared list of scenarios, expected results, owners, and review evidence is often enough to expose the important gaps. If the team cannot agree on a scenario, that is a decision to make now rather than an assumption to leave with the developer.
Keep business behaviour separate from implementation
The customer needs a reliable booking. They usually do not care which database stores it. Give engineers room to choose the implementation while agreeing the observable constraints, the source of truth, and how staff recover from a failure.
Before launch, review the critical scenarios on the actual release candidate. Record any limitations and check whether staff can realistically handle them. If every online booking still needs a phone call to repair it, the release may not test the hypothesis you started with.
Still deciding where the journey should live? Compare the practical questions in our portal and mobile app guide before committing to a channel.
Bring one customer journey to Ceyentra if you are scoping a first product. Turning that journey into a short, reviewable set of outcomes is a useful piece of work before the first development sprint.
Frequently asked questions
Are acceptance criteria the same as a feature list?
No. A feature list names capabilities; acceptance criteria describe the observable behaviour that makes each capability usable and reviewable.
Should an MVP include error handling?
Yes. Include the failure and recovery paths needed for the core journey so that the release can produce meaningful learning without confusing users.
