Build Sprint
The Build Sprint
One workstream, scoped from a written brief, built with your team or for them, and handed over running in your own environment.
Quoted per workstream, once the brief is written
Who it is for
You already know what you want built.
Some teams come to us needing their people to get fluent. Those teams want a Workshop Series or a Rollout. Other teams arrive with the thing already named: the report someone rebuilds every Monday, the intake that three people key in by hand, the deck that has to match a house standard nobody has written down.
That second conversation is a Build Sprint. One workstream at a time, scoped in writing, built against your real process, and handed over running. Training around it is optional and usually smaller than people expect once the thing already works.
How it runs
Agreed before it is built. Tested before it is accepted.
Most build work goes wrong in the same place: everyone agrees on the idea, nobody writes down what the output has to be, and the disagreement surfaces at delivery when it is expensive. So the spec comes first and the tests come from the spec.
How it works
A written brief
One workstream. What is in scope, what is out, and a short list of what we need from you before anything starts. If the brief cannot be written down, the workstream is not ready and we say so.
An output spec you sign off
What it takes in, what it emits, which surfaces it has to work on, and what it must never do. Anything your own standard has not settled is written down as an open decision with an owner and a date. Nothing gets built until you have agreed this.
The build
With your team in session, or by us and delivered running, depending on how data-heavy the work is and how much iteration it needs. Either way it lands in your environment, not ours.
A test pack, written from the spec
One row per case, with the must-pass cases marked, and each surface tested separately. A chat and an add-in fail differently, so they are checked differently.
Your people test it
Your team runs the pack and logs what they find. Testing runs on synthetic material or on closed and announced work, never on live client matters.
Triage, fix, retest
Every result is stamped with the build version it was found against, so a retest proves the fix instead of overwriting the evidence for it. The number of rounds included is named in the scope before we start.
Acceptance in writing
Measured against the bar you agreed in step two, not against a conversation at delivery.
The bar for done
Done is a line you agree to before we start.
Every must-pass case passes on every surface in scope, and no finding that produces a wrong result is still open.
A build with open suggestions is done. A build with an open wrong result is not. That line sits on the spec you signed off in step two, which means acceptance is a check against something written rather than a conversation about whether it feels finished. If your situation needs a different bar, it goes on the spec before the build starts.
What we need from you
The five things that decide how close the first build lands.
This list goes in the brief so nothing stalls halfway through. Sprints slow down over missing access and missing examples far more often than over anything technical.
A named owner on your side
One person who agrees the spec and signs the acceptance. Usually the champion who will own the workflow afterward, not whoever booked the call.
Access to the environment it will live in
The build is delivered into your own account. That needs a provisioned seat and whatever permissions the workstream touches.
Real examples of the work
Three or four examples of the input and what a good output looks like. This is the single thing that most changes how close the first build lands.
The standard it has to match
The template, the house format, the rules a person would apply by hand today. Where no standard exists yet, that becomes an open decision rather than a guess we make for you.
Material your team can test on
Synthetic, or from work that is closed and announced. A signed NDA comes before any of your data reaches us.
Frequently asked questions
It is quoted per workstream, once the brief is written. Scope drives the number, and a workstream built with your team in session and a production Skill delivered into your environment are different pieces of work. We will not quote it off a menu before there is a brief to quote against.
Those builds run on a teaching schedule, alongside the training, and the point is that your team learns to build while something useful gets made. A Build Sprint is one workstream on its own, with a written spec, a test pack and an acceptance bar. Teams usually take one after a Series or a Rollout, when the blueprint has named the next thing worth building.
No. Most teams arrive after a Series or a Rollout because that is where the list of what to build next comes from. Teams who already know exactly what they want built can start here.
Either, and it is decided in the brief. Building with your team keeps the knowledge in the building and works well when the workflow is one your people already do by hand. We build it ourselves when the work is data-heavy or needs more iteration than a live session can carry. When we build it, your named owner still agrees the spec and still runs the tests.
Every must-pass case passes on every surface in scope, and no finding that produces a wrong result is still open. A build with open suggestions is done. A build with an open wrong result is not. If you want a different bar, it goes on the spec before the build starts rather than getting negotiated at delivery.
We fix and you retest, against the same cases, with each round recorded separately. The scope names how many rounds are included. If the work turns out to be a different workstream than the brief described, that is a new brief rather than a longer sprint.
Only under a signed NDA, and only with what the workstream needs. Testing runs on synthetic material or on closed and announced work.
Have something you want built?
Tell me the workstream and I will tell you whether it is a sprint, a session inside a Series, or something you should not build at all. Thirty minutes, and you get the answer either way.