The Greenbox team has done remarkable work over the past two weeks. They Event Stormed the whole domain onto a wall. They Example Mapped their stories into concrete scenarios with rules, examples, and edge cases.
The wall looks beautiful. Sticky notes everywhere. Concrete examples for the first batch of stories. A shared understanding of what the team is building and why.
It’s week six of twelve.
Maya pulls Lee aside after the Monday standup. “We’ve spent two weeks on workshops. The wall looks great. But we haven’t shipped anything new since the subscription prototype. When do we start building?”
Lee doesn’t answer directly. Instead he asks: “What’s Tom working on right now?”
Maya knows. “The farm availability screen.”
“And Priya?”
“Delivery logistics.”
“And which of those matters more for hitting 200 subscribers by the deadline?”
Silence. Maya doesn’t know. Neither does Tom, when she looks at him. They’ve been building — Tom finished the subscription flow last week, pulled the next story off the map, started on farm availability. Priya is deep in delivery. Work is happening. But it’s happening the way it happened in week one — individually, without a shared sense of what the team is doing this week, or whether the pace is enough to hit the deadline.
Six weeks left. 200 subscribers. And the team has no way of knowing whether they’re going to make it.
The missing layer
Lee draws a rough diagram on the whiteboard. Three circles, nested.
“You’ve been working out here,” he says, pointing to the outer ring. “Event Storming gave you the big picture – the whole domain. Example Mapping gave you the detail – concrete rules and examples for each story.” He taps the innermost circle. “This is the bit you’re missing. The delivery layer. What are we doing this fortnight? What does ‘done’ look like in two weeks? How do we know if we’re on pace?”
Maya folds her arms. “We don’t have time for more process. We’ve got six weeks.”
“This isn’t more process. It’s less chaos.”
Introducing the sprint
The concept is simple: two-week iterations. The team calls them sprints, though the name matters less than the rhythm.
Every two weeks:
- Plan together what they’ll build in the next fortnight.
- Demo together what they actually shipped, to the whole team – not just the developers.
Every day:
- Check in to surface blockers before they fester. Fifteen minutes, standing up, first thing in the morning.
Three practices. Lee keeps the ceremony light deliberately. Five people don’t need a Scrum Master, a Product Owner, and a burndown chart. They need a rhythm.
Monday morning: the first sprint planning
The team gathers round the wall. Lee runs the session.
“The goal for this sprint isn’t a list of stories. It’s a sentence. What do we need to be true in two weeks that isn’t true today?”
Maya translates it: “This sprint, we ship the subscription flow end to end so we can onboard our first twenty pilot subscribers.”
Lee writes it on a card and sticks it above the story map: Sprint 1 goal: ship subscription flow, onboard first 20 pilot subscribers.
“Every story you pick should serve that goal. If it doesn’t, it doesn’t go in.”
Six stories:
Tom looks at the list. “Six? We could do ten.”
Lee shakes his head. “First sprint. You don’t know your pace yet. If you finish early, pull more. But it’s better to finish everything than to finish five of ten and feel behind.”
Tom doesn’t look convinced. Priya catches his eye and gives a small nod. She’s been on teams before where overcommitting in sprint one set a miserable tone for the whole project.
Six stories it is.
They spend twenty minutes Example Mapping the stories that haven’t been mapped yet. The confirmation email story is quick – three rules, five examples, one red card about bounced emails. The farm availability story surfaces the same questions from earlier sessions: units, deadlines, update policies. Maya resolves the critical ones on the spot. The rest become red cards for next sprint.
This is important: sprint planning isn’t just picking stories. It’s the moment where Example Mapping happens for the stories you’re about to build. Discovery and planning, in the same conversation.
The daily standup
Fifteen minutes, every morning. Three questions per person: what did I do yesterday, what am I doing today, is anything blocking me?
The first three days feel odd. The team stands awkwardly in a circle. Tom gives a forty-five second summary of his code changes. Nobody has any blockers. The standup takes four minutes. Tom mutters something about it being a waste of time.
Day four is different.
Priya says: “I’m stuck. Stripe’s webhook for failed payments doesn’t include the subscription ID in the format we expected. I’ve been debugging it since yesterday afternoon.”
Tom looks up from his phone. “I hit that last month on a side project. The subscription ID moved to a nested object. Want me to show you after this?”
“Yes. Please.”
Thirty seconds during the standup. Tom and Priya pair on it afterwards and resolve it in twenty minutes. Without the standup, Priya would have spent another half-day on it alone.
That’s the pitch for daily check-ins – not the days when everything is fine, but the one day in five when someone’s stuck and the answer is sitting three metres away.
The first sprint review
Two weeks pass. Friday afternoon. The team gathers.
Lee keeps it simple: “Show what you built. Not slides. Working software.”
Tom shares his screen and walks through the subscription flow. A customer lands on the page, picks a box size, enters payment details, gets a confirmation with a delivery date. It works.
Then Sam says: “Can I try it?”
She picks up her laptop, goes to the landing page, and starts subscribing. She gets to the box selection screen and pauses. She’s been fielding exactly this question from potential subscribers all week – explaining the difference between small and large boxes over email, over the phone, at the Margaret River farmers’ market. Three people this week alone.
“Which one’s the good one? Small or Large – what’s the difference? How many people does each one feed? There’s nothing on this page that helps them decide.”
Jas pulls up her design file. “I had comparison copy in the original mockup. It got cut when we were trying to keep the first version simple.”
Maya: “That’s not simple, that’s confusing.”
Tom: “I can add it. Half a day, maybe less.”
Sam spotted in thirty seconds what nobody caught during two weeks of development. That’s why the whole team demos, not just the developers. Sam thinks like a customer. Tom and Priya think like engineers. You need both perspectives seeing the same thing.
Here’s the sprint review scorecard:
Five done, one partial. The matching tool has the basic algorithm working but no UI yet – Maya is running it from a command line script. Lee marks it as carried over to sprint two.
Tom, who wanted ten stories, sees six was exactly right. If they’d committed to ten, the story would be “we missed our target” instead of “we nearly hit it.”
That evening, Tom mentions to Sarah that Lee was right about the six stories. “I would have overcommitted and then blamed the process,” he says.
Sarah looks up from marking papers. “You sound surprised that someone else was right.”
“I’m surprised I listened,” Tom says.
Seeing the trajectory
After the review, Lee draws a simple chart on the whiteboard. Horizontal: weeks remaining. Vertical: subscriber count. He plots where they are – week 6, 38 pilot subscribers from the manual Google Form days – and draws a dotted line from 38 to 200.
“You’ve got six weeks and you need to more than quintuple what you’ve got now. Thirty-eight said yes when there was nothing but Maya’s promise and a spreadsheet. Now you’ve got software and a team. Every two weeks, we’ll plot where you actually are. If you’re falling behind, you’ll know in two weeks, not four.”
Priya takes a photo of the chart and pins it in the team Slack channel. She updates it every Friday – it becomes her quiet ritual, the act that makes the numbers visible to everyone. Nobody asks her to. She just does it.
The first data point goes on the chart at the end of sprint one: 42 pilot subscribers. Four new signups through the self-service flow in the last few days of the sprint, after the landing page went live. The software works. Four is not very many. The line to 200 still sits far above them, and the gap between “we can take signups” and “people are actually signing up” is now a visible, numerical fact. Tom stares at the whiteboard for a moment and then goes back to his desk.
Sprint two: the rhythm clicks
Sam is answering subscriber emails from her personal Gmail. By the end of sprint one, she’s getting fifteen emails a day. She sets up a shared inbox, support@greenbox.com.au – password on a sticky note stuck to Maya’s monitor. The same three questions every week: When does my box arrive? Can I skip a week? What’s in the box? She starts a spreadsheet to track them. Mrs Patterson emails twice about her delivery day, polite both times.
Sprint two planning happens on Monday morning. Forty minutes instead of ninety.
Sprint goal: Ship the farm portal, wire up referrals, and grow to 80 subscribers.
Eight stories this time – two more than sprint one. Lee raises an eyebrow but doesn’t object.
The daily standups get faster. By day three, four minutes. On Wednesday, Jas mentions that the farm portal design has a problem: she’s designed it for a desktop browser, but Dave does everything on his phone. She knows this because Sam mentioned it in passing during Monday’s standup. Sam also remembers something from the Event Storm – Rachel’s comment about her dodgy satellite broadband, the twenty minutes to load a map. “If Rachel’s going to use this portal,” Sam says, “it needs to work on a connection that drops out halfway through a form submission.” Nobody had written that down. Sam just remembered. Jas redesigns the submission flow to save progress locally and retry when the connection comes back. It adds half a day of work and saves Rachel from losing her availability data every time her internet blinks.
On Thursday morning, Lee asks a quiet question at the standup: “What happens if Tom is sick on a Thursday and you need to deploy?”
Silence.
Priya: “I’ve never deployed.”
Tom writes a README that afternoon and walks Priya through the deploy script. By the end of sprint two, Priya has deployed twice. Their bus factor for deployments goes from one to two. It’s not a pipeline – it’s a shared script and a document. But it’s the difference between “one person can ship” and “two people can ship.”
Later that day, Tom says something that surprises everyone.
“I thought standups were a waste of time. I still think most of them are – I’ve been on teams where it was twenty minutes of people reading Jira tickets aloud. These aren’t that. Four minutes, and last week it saved Priya a day. I’m in.”
Lee smiles but says nothing.
The sprint review is smoother. The farm portal works on desktop and mobile. The landing page has comparison copy. Maya demonstrates the matching tool with a real UI. Sam has brought in 26 new subscribers through a combination of local Facebook groups and door-to-door conversations at the Margaret River farmers’ market.
Subscriber count on the whiteboard: 68. Priya updates the chart. Thirty subscribers added across four weeks of sprinting. The curve is bending the right way. Then she draws where Lee’s dotted line sits at this point in the six-week stretch – 108 – and the relief thins. They’re forty short of the linear trajectory, with one sprint left to close that gap and find another 132 subscribers on top. They always knew early growth would be slow and the curve would have to steepen at the end. Seeing it is different from knowing it.
Tom looks at the chart. “We need to more than triple this in two weeks.”
“I know,” Maya says.
Sprint three: the final push
Two weeks. One hundred and thirty-two subscribers to find. By sprint three, the rhythm is second nature – Monday morning planning and Example Mapping, daily standups, Friday demo and chart update – but nothing about the mood is routine. Maya’s been at the office until midnight on Sunday, going over the sprint plan with Lee and redrawing the assumptions behind the referral programme on the back of a receipt.
Sprint three goal: Ship delivery logistics, pause-and-resume, and the referral programme. Hit 200.
The story map for this sprint is the longest they’ve written. Eleven stories. Lee raises both eyebrows but doesn’t object – he can see what the team sees.
Tom also starts feeding Example Map output into Claude during planning: “Break this story into implementation tasks and estimate the relative complexity of each.” The LLM comes back with reasonable task breakdowns that give the team a starting point for conversation. Jas uses it differently – she feeds in the Example Map cards and asks for draft acceptance criteria, then edits them. It saves fifteen minutes of typing per story. The pattern is the same as everywhere else: the LLM is an assistant, not a decision-maker.
By Wednesday of week one, delivery logistics is working end to end. Three farms are submitting availability. Maya’s matching tool produces a packing list each Tuesday evening. The first deliveries go out on Thursday – real deliveries, not the pilot ones, through the software the team built. Pause-and-resume ships on Friday afternoon, quietly, because Mrs Patterson is going on holiday and needs it by Monday.
Subscriber count on the whiteboard, end of week one: 96. Twenty-eight new in the first week of sprint three – the fastest growth yet, but Priya runs the maths and it isn’t enough. At that pace they’ll land at 154 by Friday of week two. Maya sees the number and says nothing for a full minute.
The referral programme goes live on the Monday of week two. It’s a simple thing: if a subscriber refers a friend who signs up, both get $10 off next month’s box. Sam designed it, Jas built the flow, Tom wired it into the subscription system. By Tuesday afternoon, every new subscriber is bringing an average of 0.4 friends into the funnel. By Wednesday, the number is 0.7. Sam starts tracking referrals on a second whiteboard next to Lee’s chart – names, dates, which subscriber referred them. The board fills up faster than she can write.
Priya updates the chart on Wednesday afternoon. Subscriber count on the whiteboard: 143. Still fifty-seven short of the target, with two and a half days to go. Maya looks at it for a long time. Then she says, quietly, “It’s going to be close.”
On Thursday morning, Sam opens her laptop before her feet touch the floor and sees thirty-seven new sign-ups overnight. She refreshes, thinks she’s mis-read it, refreshes again. Thirty-seven. She calls Maya before she even stands up.
Thursday rolls. The referral flywheel is spinning for itself now – every one of those overnight sign-ups arrived with friends they’d already told about the box, and several of those friends sign up within hours of getting the $10-off code. Eight more sign-ups land during the morning school run. Five over lunch. Three in the afternoon slot. By the end of Thursday the count is 196. Sam writes it on the chart in pencil, because she’s afraid that if she uses marker she’ll jinx it.
Friday morning, 8:47am: they cross 200. Priya is unlocking the office when her phone pings. Tom, who has been awake since 5am refreshing the dashboard on his phone, is already at the cafe downstairs with two coffees in a cardboard tray. “We got the hardest one,” he says, handing her a flat white. Priya laughs so hard she nearly drops the keys.
The final sign-ups trickle in across Friday. A cluster of four late in the morning – someone’s book club. Two in the early afternoon: Dave’s neighbour and her daughter. Then a slow drip through the rest of the day, referrals chasing referrals, every ping of the dashboard another small cheer from wherever on the floor people are sitting. By 4pm Priya draws the final data point slowly, as if she can’t quite believe it.
The subscriber count on the whiteboard: 214.
For a second nobody moves. Then Sam lets out a sound that isn’t quite a word, clamps her hand over her mouth, and starts to cry. Tom says “no way” very quietly, to nobody, and then says it again, louder. Jas is already in Maya’s arms. Priya stands by the whiteboard, marker still in her hand, looking at the numbers. She’s the one who plotted every single Friday for twelve weeks. She knows what this curve looks like because she drew it. Lee is standing by the door with his hands in his pockets, smiling in the way he smiles when he’s trying not to cry himself.
Maya looks at the wall – at the sticky notes from the first Event Storm, still laminated there, at the pink hotspots, at the chart with the jagged line climbing from 38 to 214 across three sprints. It’s a real number on a real whiteboard in a real office. Two hundred and fourteen people in Perth paid them money this week because they trusted a company that, twelve weeks ago, barely existed. Greenbox is real. Not a pitch deck. Not a spreadsheet. Not Maya’s idea. A company. With customers. With a team. With software that ships boxes of produce to people’s doorsteps every Thursday.
Tom, whose default is skepticism, walks up to the whiteboard and writes “214” in much bigger letters underneath Priya’s dot. Then he adds an exclamation mark. Then a second one.
Someone orders pizza. Someone else goes down to the cafe below the office and comes back with a bottle of something that is technically champagne and practically just sparkling wine. Maya, who has been running on coffee and adrenaline for twelve weeks, takes a glass and sits on the floor with her back against the wall and laughs for the first time in about six days. Sam, who hasn’t stopped smiling, keeps pulling out her phone and looking at the subscriber dashboard and then putting it away and then pulling it out again like she can’t quite trust the number to stay there.
At some point in the evening, Dave calls from Margaret River. Maya had emailed him the number an hour earlier. He says: “I don’t know what I expected when I first met you at the market, but it wasn’t this. Congratulations, kid. I told Rachel. She cried too.” Maya laughs and wipes her eyes and tells him the next box of his tomatoes is going out to a family in North Perth who specifically requested them after reading about Dave’s farm on the about page.
Lee raises his glass at one point. “To the team that nearly broke itself in month one and put itself back together.” Everyone drinks. Nobody says anything for a while.
They did it. Not comfortably – there was a rough patch at the start of sprint two when a payment bug knocked out twenty subscribers for a day. Sam fielded the angry emails. Maya personally called every affected subscriber to apologise. One of them said: “I’m switching to something else if this happens again.” Maya asked what else. “I don’t know yet. But there must be something.” There was also a three-day window in sprint three where referral growth stalled and Maya stayed up until midnight emailing every contact she had. But the sprint rhythm gave them visibility. They could see the problem coming, adjust, and respond – instead of discovering at week eleven that they were behind.
Tom says something in the final retrospective that sticks with Lee: “In week one, I was shipping code faster than I ever had. But I had no idea if it was the right code, or if we were going to make it. Now I’m shipping at about the same pace, but I know it’s the right stuff and I can see that we’re on track. That feels completely different.” He pauses. “Week one was the wrong kind of fast.”
The total ceremony overhead: about three hours per fortnight. For that investment, the team got shared visibility, early blocker detection, regular feedback from non-developers, and a clear picture of whether they’d hit the deadline. Compare that to the four weeks the team lost in month one, and it’s not even close.
What the sprint can’t tell you
Two hundred and fourteen subscribers. Three sprints. A rhythm that went from awkward silences to four-minute standups. A team that started as five people shipping code in different directions and ended as five people who know what they’re building, why, and whether they’re on pace.
That’s a different company from the one that started twelve weeks ago.
But the sprint cadence tells the team what they’re building and whether they’re on pace. It doesn’t tell them whether the code they’re shipping is correct.
Tom has been writing code fast. With an LLM as a pair, he’s generating more code in a day than he used to write in a week. But speed creates a new problem. The code arrives quickly and looks right, but bugs are slipping through – the kind that the Example Maps would have caught if anyone had checked the implementation against the green cards. Three subscribers hit a payment edge case in sprint three that was right there on a red card from the Example Mapping session. The team has concrete scenarios with context, actions, and outcomes. What they’re missing is the bridge between those cards on a table and verified, working software.
Priya starts running through the Example Map cards one by one against the code. “This scenario works,” she says. “This one doesn’t.” She’s testing by hand. She’s catching bugs. And she’s spending two hours per story doing it. At eight stories per sprint, that’s two full days of manual checking every fortnight – a quarter of Priya’s capacity, spent reading cards and comparing them to screens. And it’s only going to get worse. The team is shipping faster every sprint. More stories means more cards means more checking. Priya can see the trajectory: by sprint six she’ll be spending half her time clicking through a browser instead of writing code.
She didn’t move to Perth for this. She moved to Perth to build things.
There has to be a better way.
There is. It starts with turning those Example Map cards into working software.
The Greenbox story continues in Shipping What Matters. I'll be writing about a few other things in the meantime -- the next chapter lands around 7 April.