Plan incremental development around usable additions to a product, then check that each addition works with what already exists. A completed screen, database table or service is not automatically a useful release. Define the user outcome, the integration evidence and the remaining exceptions before describing a slice of work as ready.
Start with a workflow that someone can perform from beginning to end. For an internal request application, that could mean submitting a request, having it decided and seeing its current state. Decide what the user can accomplish after the first addition and which related capabilities deliberately remain outside it. The boundary should make the work smaller while preserving a coherent result.
What makes an increment useful rather than merely smaller?
The November 2020 Scrum Guide describes an Increment as additive to previous Increments and verified so that they work together. It also requires an Increment to be usable. That gives an evaluation team two separate questions: can the proposed addition serve its intended purpose, and does the combined product still behave as intended? Scrum Guide.
A request-entry form alone may demonstrate layout or validation. If the intended outcome is a request reaching a responsible reviewer, stopping at the form leaves that outcome incomplete. One smaller alternative is to support a single request type through a complete review route, while deferring attachments and other categories. This is an original scoping recommendation, not a rule that every product must use that sequence.
The Agile Manifesto principles favour early and continuous delivery of valuable software. They also identify working software as the primary measure of progress. Apply those ideas by asking what a stakeholder can actually inspect or use, rather than counting completed technical layers as a substitute for a product outcome. Agile Manifesto principles.
How do you choose a coherent first slice?
Write the proposed outcome as an observable action. Specify the starting information, the user’s permitted action and the state another person should find afterwards. List excluded cases separately so that a reviewer does not mistake a deliberately narrow first slice for a complete business process.
For the request application, the first slice might allow one requester role to submit an equipment request to one review queue. A reviewer can approve or decline it, and the requester can see the decision. A later slice might add a second review group. Another might introduce fulfilment evidence. Each addition should have its own reason and checks against the existing path.
| Proposed slice | Useful outcome | Integration checkpoint |
|---|---|---|
| Submit and decide one request type | Requester sees a recorded decision | Submission, review and status use the same request identity |
| Add another review group | Correct group owns its incoming requests | Existing requests remain with their intended owners |
| Record item handover | Requester can distinguish approval from fulfilment | Handover attaches to the approved request without replacing its decision |
| Add correction handling | An authorised person can explain a changed record | Earlier decisions remain understandable after correction |
These rows are a fictional planning sequence. Change them when the real business task demands a different starting point. In particular, an approval does not itself establish that an item was delivered; preserving that distinction is part of the proposed product design.
Original release card: add a second review group
Assume the first request route is already working in a test environment. The next proposed addition assigns a second category of equipment to another review group. Prepare a release card before implementation so that testers and stakeholders can distinguish expected behaviour from a convenient demonstration.
Record the following fields:
- Outcome: the new category reaches its designated reviewers, and the requester sees the recorded decision.
- Existing behaviour to preserve: requests in the original category still reach their original review group.
- Shared identity: submission, review and requester status refer to one request record.
- Exception: the new category has no configured review group.
- Expected exception behaviour: the request remains visibly unresolved; it is not silently sent to an arbitrary person.
- Evidence: test version, category configuration, observed request states and the person who reviewed the result.
Run the ordinary new route, then the original route. Next, remove the new category’s routing configuration in the test copy and inspect what happens. Compare the observed result with the agreed exception rule. Restore the configuration before the final combined check.
If the new route works but the original route breaks, record an integration failure. If both routes work but an unassigned request disappears, record the exception failure. Avoid merging these findings into one optimistic statement that the feature is mostly complete. The release card should explain the actual remaining decision.
This exercise is not a report of tests already performed. It is a reusable way for a business reader to commission and inspect the evidence for a particular incremental change.
Where do quality and release decisions meet?
In Scrum, work is not part of an Increment unless it meets the Definition of Done. The Guide describes that definition as the formal quality state required for the product. When several Scrum Teams work on the same product, they must share and comply with the same Definition of Done. Scrum Guide.
For the review-group addition, use that shared quality standard alongside the specific release card. The card explains the behaviour of this change; the product standard supplies requirements that should not disappear whenever a new slice is planned. Examples to agree include repeatable checks, access behaviour, change traceability and the instructions needed to operate the result.
Scrum permits multiple Increments within a Sprint. It also permits delivery to stakeholders before the Sprint ends; the Sprint Review is not a release gate. That distinction should stop a team treating a calendar meeting as the reason to delay useful work or the reason to release unfinished work. Organisational release authority still needs to be explicit. Scrum Guide.
How should integration exceptions change the next slice?
Keep the evidence from a failed checkpoint close to the work it affects. Identify the broken expectation, the observed state and the person responsible for deciding the next action. Then choose whether to repair the addition, narrow its scope or postpone it. Do not reduce the quality standard to preserve a planned feature count.
The Agile principles welcome changing requirements and emphasise technical excellence and good design. These ideas support deliberate adjustment as the team learns; they do not make every requested change an immediate release commitment. The business still needs to decide what matters next, and developers need a workable route to implement it. Agile principles.
If a slice touches a payment provider, keep its provider-specific acceptance evidence separate. Use the dedicated MTN MoMo collections and callback testing guide or DusuPay eligibility and settlement guide for that integration’s detailed questions. A useful application increment does not establish merchant eligibility or successful settlement.
Close the checkpoint by recording what was actually usable, what combined behaviour was inspected and which exceptions remain open. That record makes the next addition easier to scope: the team starts from an observed product state, rather than from an accumulated collection of completion labels.
For the broader implementation brief, see software development. To discuss a proposed release boundary, bring the integration card when you get started.
By Spout Team. AI-assisted drafting by Codex using the linked primary documents; independent editorial review remains pending.