Imagine that your team has agreed on a product requirement. People seeking non-emergency care should be able to find out whether a participating clinic is still accepting walk-ins before travelling there.
That requirement gives us a direction, but it is not yet a delivery plan. Should the team begin with a national directory, predict waiting times, integrate every appointment system, or build a status page? None of those choices follows automatically from the requirement.
This article is about crossing that gap. We will take one fictional healthcare example from a desired outcome to a small, testable release. The example is informed by public evidence, but it is not a product I built and it does not describe an undisclosed gap at a named institution.
Start with the outcome
The tempting way to plan work is to begin with a feature list. A better starting point is the outcome the team wants to create.
For our clinic example, static opening hours are not enough. Singapore's Ministry of Health explains that registration cut-off times can vary with staffing, capacity, patient load, and unexpected events. Its current advice is to call the clinic before visiting when there is uncertainty (MOH).
Our desired outcome is not "publish clinic hours." It is this:
A person can make an informed plan before travelling for non-emergency care.
Every piece of delivery work should trace back to that outcome. If the connection is unclear, either the work needs a better explanation or it may not belong in the first release.
Traceability does not mean that every task must directly increase one headline metric. Reliability, accessibility, security, observability, and compliance work may protect the outcome rather than increase it. The point is to explain the relationship, not to force every concern into the same number.
Use hierarchies as tools, not laws
Many teams organize work using initiatives, projects, epics, features, stories, issues, tasks, and sub-tasks. These labels can help people navigate a large body of work, but they are not universal stages of product development.
Scrum deliberately uses a smaller model. The Product Backlog is an ordered, evolving list of what is needed to improve the product. Refinement breaks Product Backlog Items into more precise items, but Scrum does not require epics, user stories, story points, or a particular ticket hierarchy.
A practical structure for our example could be:
- Outcome: People avoid unnecessary journeys caused by uncertain clinic registration status.
- First product slice: A small group of clinics can publish a live status that anyone can view.
- Product Backlog Items: Staff status update, public status display, automatic expiry, audit history, and measurement.
- Implementation tasks: Interface, API, persistence, authorization, monitoring, tests, and deployment work needed for the selected item.
Another organization might call the slice a project or epic and the Product Backlog Items features or issues. That is fine. Clear boundaries and shared understanding matter more than matching a diagram from a project-management tool.
Slice through the product
A common breakdown separates work by technical layer:
- Design the interface
- Build the database
- Create the API
- Build the frontend
- Add tests
Those may be useful tasks, but none delivers value alone. Completing the database tells us very little about whether clinic staff can keep a status current or whether people trust it enough to change their travel plans.
A thin vertical slice crosses the layers needed to create a small, usable behavior. Our first slice could be:
An authorized staff member at a participating clinic can publish whether it is accepting walk-ins, and anyone can see that status, when it was last updated, and how to call the clinic.
Keep the pilot deliberately narrow. Use three states, accepting walk-ins, call before visiting, and registration closed. If the status becomes stale, automatically fall back to call before visiting. Include clear emergency guidance, but do not collect symptoms, diagnose a condition, or recommend treatment.
This slice gives us something real to test. Can staff update it during a busy period? Do people understand the states? How quickly does information become stale? Does it reduce avoidable calls or journeys? Those questions generate better evidence for the next slice than a large technical foundation with no user-facing behavior.
User stories are prompts, not requirements
A user story can summarize the conversation we need to have:
As a person planning a non-emergency clinic visit, I want to see whether a nearby participating clinic is accepting walk-ins and when that status was updated, so that I can avoid an unnecessary journey.
The format is useful because it names a user, a need, and a reason. It is also incomplete. It says nothing about who updates the status, when it expires, what happens when the service fails, how urgent cases are handled, or how success will be measured.
That is why I do not treat a user story as the requirement itself. A good story invites discussion. It does not replace product evidence, operational rules, designs, examples, or engineering judgment.
The GOV.UK Service Manual makes a similar distinction. A user need describes the broad problem a service must solve, while stories can help organize work that addresses that need. Preserve the connection between them so a tidy backlog does not drift away from the original problem.
Add item-specific acceptance criteria
Acceptance criteria make the behavior and boundaries of a Product Backlog Item concrete. For the public clinic status, they might include:
- When a clinic has a current status, its page shows the state and last-updated time without requiring a patient login.
- When the freshness threshold expires, the public state changes to call before visiting. It must not continue to show accepting walk-ins.
- When registration is closed, the page shows the clinic telephone number and approved non-emergency guidance. It does not make a clinical recommendation.
- Emergency guidance is present for every state and does not rely on colour alone.
- Only an authorized clinic operator can change the state. Each change records the actor, time, previous state, and new state.
- If the status service fails, the page shows status unavailable, call before visiting instead of silently displaying stale information.
These criteria do more than describe a happy path. They expose product decisions about trust, safety, accessibility, and failure. If the team cannot agree on them, the work is not ready merely because the story sounds clear.
Apply one shared Definition of Done
Acceptance criteria and the Definition of Done solve different problems.
Acceptance criteria describe the behavior or scope of one item. The Scrum Guide defines the Definition of Done as the formal description of the Increment's state when it meets the product's required quality measures. It is a shared product standard, not a separate checklist for designers, developers, and quality engineers.
For this product, the Definition of Done might require that:
- code is reviewed and integrated
- automated checks pass
- agreed security and accessibility standards are met
- audit events and operational monitoring are working
- relevant documentation is updated
- the Increment remains usable and can be evaluated with the pilot clinics
A design review or deployment checklist may still be useful. Call it what it is. Creating several role-specific "Definitions of Done" weakens the shared responsibility for product quality and encourages work to move through silos.
Production release also does not have to be a universal Definition of Done item. Scrum allows an Increment to be delivered before the Sprint ends, but an Increment may also be usable without being released immediately. The team should choose a release policy that fits its product and risk.
Refine continuously
Refinement is not a meeting where someone writes every ticket before development begins. It is the ongoing work of making Product Backlog Items smaller and clearer as the team learns.
Our first conversation might reveal that clinic staff cannot update another dashboard during peak periods. That changes the product design. The team might test an update link in an existing operational tool, assign status ownership to a specific role, or narrow the pilot to clinics that already maintain a similar signal.
Another conversation might reveal that "accepting walk-ins" sounds like a guarantee. The wording may need to communicate that registration can still change before arrival. That is a product requirement, not copy polish to leave until the end.
Refine enough to make the next decision responsibly. Do not spend weeks specifying later slices whose assumptions the pilot is meant to test.
Plan the Sprint around a goal
If the team uses Scrum, Sprint Planning answers three questions.
- Why is this Sprint valuable? The whole Scrum Team collaborates to define the Sprint Goal.
- What can be completed? Through discussion with the Product Owner, the Developers select Product Backlog Items for the Sprint.
- How will the work get done? The Developers create the plan needed to produce an Increment that meets the Definition of Done.
A suitable Sprint Goal could be:
Learn whether clinic staff can keep a live registration status current enough for patients to use safely.
The selected work might include the authorized update flow, public status page, automatic expiry, audit events, and pilot instrumentation. Developers decide how to organize and perform that work. Scrum does not require a fourth planning ceremony where a manager assigns every task to an individual.
The Sprint Backlog is also not locked. As the team learns, Developers can negotiate scope with the Product Owner without endangering the Sprint Goal. If audit integration takes longer than expected, the team might reduce visual polish or pilot breadth. It should not quietly remove the safe stale-state fallback, because that would undermine the goal and product trust.
Sprint Planning is useful when it creates a coherent goal and a realistic starting plan. It is not successful merely because every person leaves with a full task list.
Use AI to challenge the breakdown
AI can accelerate parts of this process. Given sanitized product context, it can propose alternative slices, identify missing states, draft acceptance examples, map dependencies, and generate a first test matrix.
For our clinic example, an AI assistant might ask useful questions:
- What happens when two staff members update the state at the same time?
- How does the status behave when the upstream service is unavailable?
- What information could appear in a notification or audit log?
- Which requirements need human review because they affect safety or policy?
That is valuable assistance, but fluent output is not evidence. AI does not know how a clinic actually handles a queue unless the team gives it verified context. It cannot decide the acceptable freshness threshold, approve clinical wording, or make a Sprint commitment for the people doing the work.
DORA's 2025 research describes AI as an amplifier of an organization's existing strengths and weaknesses. Clear intent, small batches, automated checks, and fast feedback make generated work easier to verify. Weak requirements allow a team to create the wrong thing faster.
In healthcare work, use only approved tools and sanitized inputs. Do not paste patient records, support conversations, or identifiable operational data into an unapproved model. AI may help structure the work. People remain accountable for the evidence, policy, privacy, quality, and release decision.
From delivery back to learning
Finishing the slice is not the end of the story. The team must compare what happened with the outcome it intended to create.
Did staff keep statuses current? Did users understand when to call? Were any clinics shown as accepting walk-ins after their information became stale? Did the service reduce avoidable journeys without delaying urgent care or creating unreasonable staff work?
The answers should change the Product Backlog. The next slice might improve the staff workflow, add another access channel, or test alternative wording. It should not automatically be the largest feature from the original roadmap.
User stories still have a place in modern product development. Their value is not the sentence template. Their value is the conversation they start and the traceability they preserve from a real need to a small piece of work.
If you want to step back one level, Why Product Requirements Matter examines how a team finds the right outcome before it creates the first story. For the wider Scrum lifecycle, including discovery, reviews, releases, and retrospectives, continue with Join the Scrum.