Discovery, Scoping, and Sequencing Customer Work

After this lesson, you will be able to agree on a first slice of work with a customer, explain what it includes, and sequence the next steps around user value, risk, and evidence. You will also get a scope and sequencing sheet you can adapt for a project. Examples use NorthPort Freight, a fictional logistics company. All workflows, decisions, and records in the examples are invented.

A request may be clear enough to start a conversation and still be too broad to build. In the earlier example, NorthPort's dispatcher asks for help catching bad orders. The team still needs to learn which cases matter, which system information is available, who can approve access, and how a person should respond to a flag. Scoping turns that uncertainty into a small, reviewable piece of work with a purpose and a decision point.

Discovery is for answering a decision

Discovery is a focused period of learning about the problem, users, current process, constraints, and possible ways forward. It helps the team decide whether and how to proceed. A discovery sprint is a bounded cycle with a goal, questions, research or technical checks, and a review of what the team learned. The length depends on what the team needs to decide and the access it has. Unknowns or unresolved approvals may remain when a sprint ends.

Before each cycle, state the decision the team needs to make. For example: "Can we show the two order references in one read-only view using an approved data source?" That question identifies what to investigate. It does not claim the interface exists or that the customer has approved its use.

Then list the evidence that would help answer it. A dispatcher might walk through a fictional or approved example. A system owner might confirm whether the fields exist in a permitted source. A developer might inspect an API description or a sandbox. The team can compare the evidence with the open questions in its requirement log.

GOV.UK's discovery guidance says teams should understand the problem, users, and constraints before committing to build. Its agile delivery guidance describes iterating: build something that addresses a user need, show it to users, use their feedback, then decide what to do next. These pages address public services; adapt the practices to the customer's delivery and governance process. The AI Product Builders lesson on scoping a first version provides another product-focused exercise.

End each discovery cycle with an explicit decision. The team might agree to test a small option, ask a system owner to resolve access, revise the problem statement, or stop. Record what the evidence supports and what remains unknown.

Define the first slice

A slice is a small piece of work that produces an outcome a user or reviewer can inspect. A thin vertical slice passes through the parts needed for one narrow task, such as input, processing, and a visible result. It connects those layers to a user-visible task; a standalone database table covers one layer. The slice can be a prototype, a manual process supported by a simple tool, or a production change when the evidence and approvals allow it.

For the fictional NorthPort exercise, consider a read-only review for one type of order mismatch. A thin slice might take a synthetic order record, show the ordering-system reference beside the dispatch reference, and let a dispatcher inspect both values before deciding what to do. It has an input, a comparison, and a result a person can review. It does not change either source record.

The team still needs to confirm that the fields are meaningful, the read path is approved, and the display supports the user's task. If those questions remain open, the team may choose research or a mockup as its next work.

A useful first slice has a boundary. State:

• User and task: who will try it and what they are trying to do.
• Starting condition: which event or record begins the workflow.
• Included behavior: what the slice will show or allow.
• Excluded behavior: nearby work the team is leaving out for now.
• Evidence: how the team will check the behavior and learn from the user.
• Safety and quality limits: data, access, error handling, and review conditions that must hold.
• Decision point: who will review the result and what choice follows.

This boundary helps a team avoid the vague promise "we will build an order checker". A reviewer can understand what the first version will do, what remains outside it, and what evidence is needed before expansion.

Use scope, time, and quality to discuss trade-offs

The scope-speed-quality triangle is a teaching aid for a conversation. Scope is the amount of work included. Speed is how soon the team can learn from or deliver that work. Quality describes whether it behaves correctly and meets the agreed conditions, including safety and access requirements. Teams often adjust the size or timing of a slice as they learn. Use the triangle to make choices visible; it offers no universal calculation and gives no reason to lower agreed quality conditions.

Imagine that NorthPort asks for an automated correction as well as a mismatch flag. Automatic correction could save a dispatcher a step, but it adds a write action and needs rules for conflicting or incomplete records. If the team has not confirmed those rules or write permissions, it can preserve the quality and access guardrails by narrowing the first slice to read-only review. The customer can then decide whether further investigation is worthwhile.

With a fixed date, discuss which parts of the scope can fit and what evidence may be missing. A fixed scope needs an estimate for the work and review it requires. Keep agreed quality conditions visible, then identify the smallest slice that can meet them. Put the decision in writing so the customer can see what changed and why.

Treat quality conditions as guardrails. If a requested date cannot accommodate the agreed checks, say which checks will remain incomplete and ask the decision owner how to proceed. Describe an untested prototype accurately; it is not ready for production. Keep safety, privacy, correctness, and authorization conditions visible even when the schedule is tight.

Sequence work by value and risk

Value describes the user or organizational benefit a piece of work is expected to provide. Risk describes what could go wrong or what uncertainty could prevent the work from succeeding. A high-risk item may be an assumption to test before other work depends on it.

Start with the desired user outcome, then compare candidate work. Ask how directly each item supports the task, what evidence supports that value, what could block it, and what the team would learn by checking it. Do not use a made-up score to make a preference look objective. A short written reason is useful even when the team uses a ranking board.

For example, consider these fictional NorthPort candidates:

The order can change when evidence arrives. If the field definitions are unclear, settle that before building a mockup that depends on them. If a mockup can test whether the display makes sense without connecting to a system, use it to learn before asking for integration access. Keep dependencies visible because a team may need another owner or environment before a technical task can begin.

One practical ordering rule is to test high-impact assumptions before committing dependent work. If an assumption is wrong, what will it cost to discover it later? Who can resolve it? Can the team run a small test without creating a production risk? A short read-only investigation may come before feature work because it determines whether the rest of the plan is possible.

Say no to a request while keeping the outcome in view

An FDE sometimes needs to decline a requested feature or postpone it. Explain the reason with evidence and offer a next step the customer can choose. Start by restating the outcome the request is meant to support. Then identify the constraint or unresolved question, explain its effect on the current plan, and offer an option that fits the known conditions.

For example, if NorthPort asks for automatic correction but the system owner has not approved write access, the FDE can say: "The goal is to reduce the time spent resolving reference mismatches. We have not confirmed an approved way to write corrections or the rule for choosing the right value. I recommend starting with a read-only comparison and asking the owner to confirm the policy before we plan automated changes. Does that meet the review need for this first step?"

The wording states the current boundary and asks the customer to choose a next step. The feature's feasibility and policy remain open until the owner confirms them. Record the request, evidence, proposed alternative, decision owner, and response in the scope sheet or requirement log.

If the customer disagrees, find out which evidence or constraint they see differently. The outcome may be a new discovery task, an escalation to an authorized owner, a revised slice, or a documented decision to accept a known risk. Do not let a verbal request silently override access rules or quality conditions.

Keep assumptions visible

An assumption is a belief the plan currently depends on but the team has not confirmed. Examples in the fictional exercise could include "both source fields can be read together" or "the dispatcher can review the comparison before acting". Write each assumption in plain language, name the person who can confirm it, and set a point when the team will revisit it.

Separate assumptions from constraints and decisions. A constraint is a condition the team must respect, such as an approved data boundary. A decision records a choice made by an authorized person, such as which source field controls a correction. An assumption still needs evidence or an owner decision. If a decision is later revised, record what changed and why.

When an assumption fails, update the plan and record what the new evidence changes. The team may narrow the slice, choose another approach, ask for access through the proper process, or stop. Keep dependent tasks from proceeding as if the original belief were still true.

Scope and sequencing sheet

Use this template to connect an outcome to a first slice, its evidence, and the next decision. Copy a row for each candidate item. Keep uncertainty and ownership visible instead of filling blanks with guesses.

For an ordered plan, add candidate work items:

The template is deliberately small enough for a working discussion and detailed enough to expose missing owners or evidence. A large engagement can use more formal planning tools. Keep the information consistent with the team's requirement log so the same request does not get two conflicting statuses.

Mistakes beginners make

1. Treating the whole request as the first deliverable. Define one user task and the smallest result that can be checked.
2. Calling a technical layer a thin slice when no user can inspect the result. Trace one narrow task from input to visible outcome.
3. Ranking work by preference alone. Record the user value, supporting evidence, and uncertainty for each candidate.
4. Treating a discovery sprint as a promise to finish every unknown. End each cycle with a decision and a visible list of remaining questions.
5. Saying no without explaining the constraint or offering a useful next step. Connect the boundary to evidence and an alternative.
6. Letting assumptions live only in meeting notes. Name them, assign owners, and revisit them before dependent work proceeds.

Recap and try it yourself

Discovery should answer a decision. A useful first slice covers one task a user can inspect, with clear inclusions, exclusions, evidence, and quality conditions. The scope-speed-quality triangle helps explain choices; the sequence should reflect user value, risk, and dependencies. Test important assumptions early, keep decisions visible, and explain scope changes with evidence.

Try it: use the fictional request, "Catch bad orders." Write one customer outcome, then list three possible work items. Mark the expected value, the largest uncertainty, who can resolve it, and the next check for each. Choose a first slice that uses synthetic data and does not assume unapproved access. Fill in the scope and sequencing sheet, including one excluded request and one checkpoint where the customer can review the evidence.

Sources

Checked on 5 November 2026. Delivery guidance varies by organization; agree the customer's governance, quality, and approval process for each engagement.

• How the discovery phase works, GOV.UK Service Manual, for learning about users, constraints, assumptions, and the decision to continue before committing to build.
• Core principles of agile, GOV.UK Service Manual, for iterative work informed by user feedback and regular planning. It is guidance for government services.
• Planning in agile, GOV.UK Service Manual, for visible plans, dependencies, and revisiting priorities as new facts arrive.
• Making prototypes, GOV.UK Service Manual, for using prototypes to explore and test options before committing to production work. Its security and production limits are also noted there.
• Principles behind the Agile Manifesto, for early delivery of customer value, changing requirements, and frequent delivery as principles. The scope-speed-quality triangle in this lesson is a teaching aid, not a principle quoted from the manifesto.