How Sprints Work

A sprint is not a to do list. It is a loop. And we run that loop the same way every time.

If you have read what a hypothesis is, you know we test one belief at a time. A sprint is the container for that test. Three to four weeks. One hypothesis. One primary metric. Then we write it up and pick the next move.

Here is what that looks like from your side and ours.

What a sprint is (3 to 4 weeks)

Think of a sprint as hypothesis → implement → measure → readout. Four steps. That is the whole cadence.

We start with the hypothesis. You have seen the shape: belief, change, metric, timeframe. That belief comes from Baseline, funnel, and sessions. Not from opinion.

Then we implement. We build on the store and on tracking for that hypothesis only. If the belief is about clarity above the fold, we change what is needed to test that belief. Could be headline and visual together. But it is still one hypothesis. You judge the belief, not the number of elements we touched.

Then we measure. Not for a day. For the sprint window. We collect the primary metric tied to the hypothesis and watch what else moves or does not. Example: Example: one sprint = 3 to 4 weeks of collection, not a snapshot.

Then readout. We write up what moved, what did not, what we learned about your buyer, and what we think you should test next. That document is the bridge to the next sprint.

One more thing. A sprint is not a retainer with random tasks. If it is not tied to the hypothesis and its metric, it does not go in the sprint. That constraint is what keeps the learning clean.

Baseline vs Sprint 1 vs Sprint n

Baseline is the before picture. We map where the store leaks right now. By funnel step. By device. By traffic source. That map tells us where the first hypothesis should live.

Sprint 1 is the first test against that Baseline. It is the hypothesis we believe has the most impact given what Baseline showed. We do not skip Baseline even when the brief feels obvious. I have been in rooms where everyone agreed the PDP is the problem and Baseline showed the real drop was between landing and PDP. If we had started on PDP, we would have learned nothing.

Sprint n is every sprint after. Each one is chosen from the previous readout. Not preplanned in detail. The backlog exists, it is ordered, but the readout reorders it. That is compounding. Earlier sprints make later sprints sharper and less risky.

A quick note on numbers here. If we need to show shape in an outline, we will write TBD, placeholder, not a result or Example: baseline covers add to cart → checkout → purchase. When we publish a real baseline, it will be labelled with source and window. No mystery numbers.

And yes, we keep that split in mind: Example: site conversion vs Meta spend efficiency tracked separately. Baseline already separates those two stories. Sprints keep them separate too. More on that in what you get in a readout.

The loop: hypothesis → implement → measure → readout

Let me walk the four steps like you would live them.

Hypothesis. We restate the belief, the change, the metric, and the timeframe in plain language. You can read it in under a minute and know what we are betting on. If you are new to that shape, start with what a hypothesis is. It is five minutes and will save us twenty questions later.

Implement. This is on us. Pages, tracking, and the specific build for the hypothesis. We keep the store stable while we work. If the hypothesis needs a new section above the fold, we build it. If it needs tracking for a specific step, we fix tracking there first. We do not rebuild the theme for fun. We build for the bet.

Measure. We let the change run across the sprint window and collect. The primary metric is judged at the end. Secondary steps are watched for context. We do not call a winner on day three. Traffic in the GCC dips and spikes by day of week, by payday, by campaign. The window matters.

Readout. This is on us too. Written, short, and the basis for the next decision. We show did the primary metric move in the timeframe, what else moved or did not, what we now believe about the buyer, and the next hypothesis with its own metric and timeframe. Every readout ends with so next we test... in explicit form.

The loop never changes. Only the hypothesis changes. That is the discipline.

We do not claim statistical significance guarantees. Some stores do not have the volume for a clean split test in one sprint. In those cases we still learn, we just call it what it is. We cover that honesty language, directional and up to, properly in the Readout doc. Mentioning it here so you know it exists.

Ownership split (client = Meta; Convfetti = pages, tracking, readouts)

I want this to be explicit because most engagements get fuzzy here. Then no one knows who caused what.

You own Meta. Or acquisition more broadly. Targeting, creative, budget, account. You live there. We do not manage your ads and we do not want to take credit for a better audience.

We own pages, tracking, and readouts. The store experience that turns clicks into purchases. The measurement that tells us if the change worked. And the written readout that picks the next move.

The seam is where Meta hands off to the landing page and PDP. That seam is where most leakage lives. Example: landing page is where ad promise meets product. If the ad says one thing and the page says another, conversion dies between the click and the scroll. That is not a Meta problem and not just a page problem. It is a handoff problem, and it is our job to fix the page side of it.

We keep this split respectful and clean. We will never blame Meta in a readout, and we will never let a tracking fix take credit for a site change. Those stories are counted separately, which is exactly what the Readout doc shows you.

This split is also why P11 in our problem map is about ad promise → landing → PDP, not tracking truth. Tracking is P5. We keep them apart.

Why one at a time (no parallel big builds)

Parallel big builds hide what worked. You do three large changes, the number moves, now what? You cannot repeat it because you do not know which change mattered. Or the number does not move and you throw all three out. Waste.

One at a time gives a clean read. It also keeps the store stable. Fewer regressions. Faster to revert if needed. The store is making money while we test. We do not gamble that.

We sequence, we do not stack. The backlog has plenty in it. We choose the most important item after each readout. Not before. That is the difference between a plan and a system.

Does that mean we never do parallel work? No. Small fixes that do not affect the primary metric can ride along. A typo, a broken link, a speed fix that is clearly not the hypothesis. But any big build that could move the primary metric rides alone. That is the rule.

If you want the logic behind isolating hypotheses, that lives in the Hypothesis doc. If you want how we choose Sprint 2 from Sprint 1 data, that is in what you get in a readout. They are two sides of the same constraint.

Plans that use sprints (light, link out)

Three plans run on this sprint cadence. Keeping this light on purpose, detail lives on pricing.

HyperCRO is for faster cadence when you want more bets per quarter. Conversion Sprint is the core sprint engagement most stores start with. Growth Optimise is for compounding over quarters, where the sprints build on each other and the backlog gets sharper over time.

That is it for this page. If you need scope, timeline, or price, that lives with engagement plans on our pricing page. One link at the end, no pitch in the body.

What to read next. If you have not seen it, what a hypothesis is gives you the shape we test. And what you get in a readout shows you what accountability looks like at the end of each loop.