The BMAD documentation makes a point that is easy to miss: small and large changes do not need entirely different delivery philosophies. They enter the same loop at different points, and go to different depths.
A clear one-line defect can move almost directly to build. A new regulated customer-onboarding capability needs discovery, requirements, UX, architecture, work breakdown, implementation and assurance. Both are the same kind of work: turning an intent into a verified change. What differs is how much uncertainty and risk has to be removed before anyone writes code.
This part walks through that loop, first in general and then for one real-sized change at Mopane Logistics.
Size first, then plan
BMAD's planning guidance asks one question before anything else: how big and how clear is this piece of work? The stable documentation sorts work into four sizes:
- Trivial: small and well understood. It goes straight to the build step.
- One session: clear enough to specify and build in a single sitting.
- Epic-sized: several related stories that need a plan and some architecture.
- Project-sized: a new product or a substantial capability that needs discovery, product requirements, UX and architecture before stories.
Size is not the only input. A change that is small in lines of code can still be risky: a one-line edit to how a payment is calculated deserves more scrutiny than a one-line copy change. In practice, teams combine size with consequence, and our reading of the loop looks like this:
The arrows matter more than the boxes. There is one route to production, through test, review and a decision to release or revise. What changes is where you join it.
The six practical stages
1. Frame the intent
State the outcome, the user, the constraint and the reason. Avoid starting with a preferred implementation unless it really is a constraint.
Weak:
Build a chatbot using framework X.
Stronger:
Reduce first-line support effort for password-reset and account-unlock requests, while keeping identity controls and a human escalation path.
The stronger version tells everyone, including the AI tool, what success means and what must not be traded away to get it.
2. Gather evidence
Good delivery context includes more than stakeholder opinion. It may include user journeys and service data, the existing code and architecture, security policies, integration contracts, operational incidents, regulatory obligations, and performance and cost baselines.
The method should help the team separate three kinds of statement: facts it has checked, assumptions it is making for now, and open questions someone has to answer. An AI tool is very good at producing fluent text that blurs the three. The team's job is to keep them apart.
3. Define the specification
A useful specification tells the delivery system what success means. It covers the problem and the desired outcome, the actors and their journeys, the functional behaviour, quality attributes such as performance and availability, constraints and exclusions, the evidence that will prove acceptance, and the risks and decisions still open.
A specification is not a promise that nothing will change. It is the current, reviewable statement of intent. Our article on the anatomy of a useful specification goes into what separates a specification that guides work from one that only fills headings.
4. Shape the architecture
Architecture turns intent into the technical decisions that have consequences. It should explain boundaries, responsibilities, flows, data, identity, failure handling, observability and deployment.
Do not draw a cloud-icon diagram just because an architecture step exists. The right views depend on the decision in front of you. A change that adds one field to an existing screen may need no architecture at all. A change that introduces a new external dependency always does.
5. Build in reviewable increments
The work is broken into units small enough to build and verify. Each unit should trace back to the intent, carry the context it needs, and define the evidence that proves it is done. In the stable release, this is the job of a single build skill: trivial changes go to it directly, and larger ones arrive there as stories that already carry their context.
6. Review and learn
The final question is not "did the agent finish?" It is:
Does the delivered change satisfy the agreed intent, without breaking the constraints we discovered?
Failures and new knowledge should flow back into the project's context. Otherwise the method becomes a one-way document factory, producing paper that the next change never reads.
One change, end to end
Mopane Logistics is fictional, and its systems and figures are illustrative. Mopane's customers are retailers and wholesalers, and their receiving staff spend a surprising amount of time phoning Mopane's call centre to ask when a delivery will arrive. The product owner proposed sending WhatsApp updates to the receiving contact at each customer site as a consignment moves.
On the sizing question, this was clearly more than one session. It touches Dispatch, the messaging integration, customer contact data and consent. It was not project-sized either: no new product, no new platform. The team treated it as epic-sized, which meant a specification, targeted architecture and a few stories.
Here is what each stage produced.
| Stage | Mopane's output |
|---|---|
| Intent | Reduce "where is my delivery?" calls from customers' receiving staff, without exposing customer or consignment data to the wrong person |
| Evidence | Three months of call-centre logs by reason; the consignment states Dispatch actually records; which customers had opted in to messages; the messaging provider's cost per message |
| Specification | Supported events, opt-in and opt-out, message language, retry behaviour, what happens when a number is wrong, escalation to the call centre, and acceptance tests for each |
| Architecture | A Dispatch status event, a small message service, a mapping from customer site to receiving contact, an audit trail, and a failure queue for messages that cannot be delivered |
| Build | One event, "out for delivery", for one depot, Pietermaritzburg, behind a feature flag |
| Review | Message delivery rate, duplicate prevention, opt-in accuracy, and the change in call volume from Pietermaritzburg customers |
Three moments in that sequence show the value of the stages.
The evidence stage changed the scope. The call-centre logs showed that most delivery calls came on the day of delivery, not before. That made "out for delivery" the event worth building first, and moved "collected" and "in transit" to later.
The specification stage surfaced a privacy question. The first draft of the specification, written with the analyst and product perspectives, assumed the receiving contact was always a Mopane customer's employee. The tester asked what happens when the contact on file is a former employee's personal number. That became an explicit requirement: messages go only to contacts confirmed in the last twelve months, and the message includes nothing beyond the consignment reference and an arrival window. Under POPIA, Mopane is the responsible party for that contact data, and the messaging provider is an operator processing it on Mopane's behalf. Both facts shaped the design.
The architecture stage found a duplicate risk. Dispatch can record "out for delivery" twice when a vehicle returns to the depot and leaves again. The architecture added an idempotency rule: one message per consignment per delivery attempt, keyed on the consignment and the attempt number.
None of these needed BMAD to discover them. All of them needed someone to ask at the right point, and to record the answer where the build step would find it. That is what the stages are for.
What the method preserved
When the change reached review, the reviewer could trace each acceptance test back to a line in the specification, and each line in the specification back to the intent or the evidence. When the call-centre manager asked, three weeks later, why the messages did not include the driver's name, the answer was in the specification: the team had chosen not to share staff personal information in customer messages, and had recorded why.
BMAD helps preserve that chain. The team still has to decide whether the evidence is sufficient, and whether WhatsApp is the right channel at all. In Mopane's case, it was right for receiving staff, who already use WhatsApp at work, and the specification records email as the fallback for sites that opt out.
The flag came off for Pietermaritzburg after two weeks. The other depots followed one at a time. That is Part 3's subject in miniature: start bounded, measure, expand when the evidence supports it. For a view of how discovery uncovers work that documentation misses, see the process map is usually fiction.
The short version
One loop, different depths. Small and large changes follow the same route to production; they join it at different points.
Size before you plan. Trivial, one session, epic-sized and project-sized changes need different amounts of planning. Consequence matters as much as size.
Six stages, each leaving an artefact. Frame the intent, gather evidence, specify, shape the architecture, build in increments, then review and learn.
Keep facts, assumptions and questions apart. An AI tool will blur them unless the team insists.
Learning goes back into context. Otherwise the method becomes a document factory.
Previous: Part 1, what BMAD actually is. Next: Part 3, getting started without drowning in process. All parts are on the series page.
How CloudNala can help
We help delivery teams take one real change through a structured loop from end to end. We frame the intent with the people who own the outcome, gather the evidence that changes scope, and write specifications that keep facts, assumptions and open questions apart. Then we match the architecture to the decision the change actually needs. The result is a worked example in your own repository that your team can copy for the next change.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan an AI Delivery Pilot or write to us at consult@cloudnala.co.za