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 looks at the wall, then back at Maya. “You’ve been building. You just haven’t been doing it with a rhythm.”
He’s right, in a frustrating way. Tom has been coding the whole time. He finished the subscription flow last week, pulled the next story off the map, started building the farm availability screen. Priya is working on delivery logistics. 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.
Tom finishes something, picks up the next thing. Priya finishes something, picks up the next thing. Nobody is asking: “What are we doing together this fortnight? Is it enough? Are we on track?”
Six weeks left. 200 subscribers. And the team has no way of knowing whether they’re going to make it.
The planning onion
Lee draws a rough diagram on the whiteboard. Concentric circles, like an onion.
“You’ve been working the outer layers,” he says. “Event Storming gave you the big picture – the whole domain in a day. Example Mapping gave you the detail layer – concrete rules and examples for each story.”
He taps the centre of the onion. “This is the bit you’re missing. The innermost layer. What are we doing this fortnight? What does ‘done’ look like in two weeks? And how do we know whether 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,” Lee says. “It’s less chaos.”
Introducing the sprint
The concept Lee introduces is simple: two-week iterations. The team calls them sprints, though the name matters less than the rhythm.
The sprint rhythm has two parts: a fortnightly cycle and a daily heartbeat.
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.
That’s it. Three practices. Lee is deliberately keeping the ceremony light. Five people don’t need a Scrum Master, a Product Owner, a burndown chart, and a Definition of Done document. They need a rhythm.
“Think of it this way,” Lee says. “The Example Maps tell you what to build. The sprint tells you when you’re building it and whether you’re on track. Without the sprint, you’ve got a pile of beautifully mapped stories and no idea if you’re working fast enough.”
Monday morning: the first sprint planning
The team gathers round the wall of sticky notes from the Event Storming and Example Mapping sessions. 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?”
He looks at the Event Storm wall, at the hotspots they identified. The critical path is clear: subscriptions first. Nothing else works without paying customers.
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.
“That’s your sprint goal,” he says. “Every story you pick for this sprint should serve that goal. If it doesn’t, it doesn’t go in.”
The team pulls stories from the subscription flow – the critical path from the Event Storm. Six stories:
Tom looks at the list. “Six? We could do ten. We’ve already got half the subscription code written.”
Lee shakes his head. “It’s your first sprint. You don’t know your pace yet. Pick six. If you finish early, pull more. But start conservative. It’s much better to finish everything and pull more 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.
Lee adds one more step. “Stories three and five haven’t been Example Mapped yet. Let’s do that now.”
They spend twenty minutes Example Mapping the confirmation email story. It’s quick – three rules, five examples, one red card about what happens if the customer’s email bounces. The farm availability story takes longer. It surfaces the same questions from the earlier Example Mapping posts: units, deadlines, update policies. Maya resolves the critical ones on the spot. The rest become red cards for next sprint.
This is important. The sprint planning session 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, in the same hour.
The daily standup
Lee introduces the daily check-in. Fifteen minutes, every morning. Three questions per person: what did I do yesterday, what am I doing today, is anything blocking me?
“It’s not a status report,” Lee says. “It’s a blocker detector. If nothing’s blocked, it takes five minutes and you get on with your day.”
The first three days feel odd. The team stands awkwardly in a circle. Tom gives a forty-five second summary of his code changes. Priya mentions she’s working on the Stripe integration. Jas says she’s finishing the landing page design. Sam reports he’s been emailing potential pilot subscribers. Maya talks about farm conversations.
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. I think the payload structure changed in their latest API version.”
Tom looks up from his phone. “I hit that last month on a side project. The subscription ID moved to a nested object. I’ve got a working example. Want me to show you after this?”
“Yes. Please.”
The conversation takes 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, probably ending up on Stack Overflow, then raising it in a Slack thread that Tom might not read until evening.
Thirty seconds of standup saved half a day of debugging. 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 doesn’t know that the answer is sitting three metres away.
The first sprint review
Two weeks pass. Friday afternoon. The team gathers for the sprint review.
Lee keeps it simple: “Show what you built. Not slides. Not a progress report. 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. The whole team watches it happen live.
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. And here’s the page, with no answer.
“Which one’s the good one? Small or Large – what’s the difference? How many people does each one feed? I’ve been emailing potential subscribers all week and three of them asked me that question. There’s nothing on this page that helps them decide.”
The room goes quiet for a beat.
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. If people can’t tell the difference between the boxes, they won’t subscribe at all.”
Tom: “I can add it. Half a day, maybe less.”
Lee: “Good. Put it on the board for sprint two. But notice what just happened – Sam spotted a problem in the first thirty seconds of using the product that nobody caught during two weeks of development. That’s why we demo to the whole team, 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, they’d have finished five and a half, and 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 does something that changes the mood of the entire team.
He draws a simple chart on the whiteboard. Two axes. Horizontal: weeks remaining (6, 5, 4, 3, 2, 1). Vertical: subscriber count.
He plots where they are: week 6, 0 pilot subscribers (the old prototype subscribers don’t count – the new system is a fresh start).
He draws a dotted line from 0 to 200, representing the pace they need.
“You’ve got six weeks and you need 200 subscribers. That’s roughly 33 new subscribers per week. But it won’t be linear – the first two weeks are about getting the pilot running. You’ll probably have 20 by the end of sprint two, and then growth needs to accelerate as word of mouth kicks in and Sam’s marketing gets traction.”
Maya stares at the chart. “Is that realistic?”
Lee shrugs. “I don’t know. But now you can see it. Every two weeks, we’ll plot where you actually are against where you need to be. If you’re falling behind, you’ll know in two weeks, not ten.”
That visibility changes something. For the first time, the team can see the shape of the challenge. It’s not abstract any more – “200 subscribers by week twelve” – it’s a line on a wall. They can see the gap between where they are and where they need to be. And they can see that the gap is closable, if they keep the pace.
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.
Sprint two: the rhythm clicks
Meanwhile, Sam is answering subscriber emails from her personal Gmail. By the end of sprint one, she’s getting fifteen emails a day – questions, complaints, delivery queries. She sets up a shared inbox, support@greenbox.com.au. It’s not a helpdesk. It’s a shared email account with the password on a sticky note stuck to the side of Maya’s monitor. But at least Maya and Jas can see what customers are asking. Sam notices patterns almost immediately: 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.
Sprint two planning happens on Monday morning. It takes forty minutes instead of the ninety minutes sprint one took. The team knows the format now.
Sprint goal: Ship the farm portal and launch the pilot with 20 subscribers.
They pull eight stories this time – two more than sprint one. Lee raises an eyebrow but doesn’t object. The team finished five and a half stories last sprint. Eight is ambitious but not reckless, especially since some of them are smaller (like adding box comparison copy to the landing page).
The daily standups get faster. People know the rhythm. By day three, the check-in takes four minutes. Most days, nobody has a blocker. But the days when someone does – those are the days the standup earns its keep.
On Wednesday of the first week, Jas mentions that the farm portal design has a problem: she’s designed it for a desktop browser, but Dave – one of the partner farms – does everything on his phone. She knows this because Sam mentioned it in passing during Monday’s standup. Jas didn’t have to find out the hard way three days before launch.
On Thursday morning, Lee is sitting in on the standup. He asks a quiet question: “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 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 the standup 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 than the first one. 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 recruited 22 pilot subscribers through a combination of local Facebook groups and door-to-door conversations at the Margaret River farmers’ market.
Twenty-two. They needed twenty. The chart on the whiteboard gets its first real data point, and it’s above the dotted line.
Discovery inside the sprint
Here’s the part that most teams get wrong about sprints: they treat discovery and delivery as separate activities. Discovery happens before the sprint. Delivery happens during. Once you’re “in the sprint,” you build.
The GreenBox team doesn’t work that way, and it’s because Lee set it up differently from the start.
Monday morning of each sprint has two parts. The first hour is sprint planning: picking stories, setting the sprint goal. The second hour – or sometimes just thirty minutes – is Example Mapping the stories that need it.
Not every story needs an Example Mapping session. Some are straightforward enough that a two-minute conversation suffices. But the ones that are complicated, ambiguous, or touch multiple parts of the system? Those get mapped. Right there, Monday morning, before anyone starts building.
This means discovery happens continuously, inside the delivery rhythm. Not as a separate phase that finished two weeks ago, but as an ongoing practice embedded in the sprint cadence. The team discovers on Monday, builds Tuesday through Thursday, and demos on Friday. Same rhythm every fortnight.
When a story turns out to be more complicated than expected mid-sprint – say, the delivery logistics story that nobody realised needed postcode validation – the team doesn’t panic. They pull out the Example Mapping cards, spend twenty minutes with Maya, and figure out the rules. The sprint cadence doesn’t forbid discovery. It creates a container for it.
Event Storming is the big-picture technique you use less frequently – once at the start, or when entering a new area. Example Mapping is the one you use every sprint, sometimes every story. It’s the discovery technique that lives inside delivery.
LLMs as planning assistants
The team also finds a use for LLMs during sprint planning.
When the team picks a story for the sprint, Tom sometimes feeds the Example Map output into Claude and asks: “Break this story into implementation tasks and estimate the relative complexity of each.”
The LLM comes back with a reasonable task breakdown – “set up the Stripe webhook listener, build the subscription data model, write the confirmation email template, add the delivery date calculation” – along with rough complexity notes. Tom doesn’t trust the estimates blindly, but they’re a useful starting point for conversation. “Claude thinks the webhook listener is the complex bit. I agree – we’ve already got the data model mostly done.”
Jas uses it differently. She feeds in the Example Map cards and asks for draft acceptance criteria in plain English. The LLM produces something close to what the team agreed on, which Jas edits and pins to the story card. It saves fifteen minutes of typing per story, and the output is more consistent than if five different people wrote the criteria from memory.
The pattern is the same as everywhere else in this series: the LLM is an assistant, not a decision-maker. It can break down a story into tasks, but it can’t decide which stories matter. It can draft acceptance criteria, but it can’t replace the twenty-five-minute conversation where Maya, Tom, and Priya figure out what “done” actually looks like. The thinking is human. The typing is increasingly not.
Progress tracking at startup scale
Lee keeps the tracking deliberately simple. No burndown charts. No velocity calculations. No earned-value metrics.
Two numbers, updated every Friday:
- Stories done this sprint vs stories planned.
- Subscriber count vs target pace.
He plots both on the whiteboard chart. That’s it.
Maya asks: “Shouldn’t we track velocity? Story points? Something more sophisticated?”
Lee: “Not yet. You’re five people. You’ve done two sprints. You don’t have enough data for velocity to mean anything, and you don’t have enough process for story points to be calibrated. Track the two things that matter: are you finishing what you planned, and are you hitting the business target? Everything else is noise at this stage.”
He’s right. At five-person scale, with a twelve-week deadline, sophisticated tracking creates the illusion of precision without actually improving decisions. The whiteboard chart – updated by hand, photographed by Priya every Friday – tells the team everything they need to know.
When the team later grows to fifteen people working across three streams, they’ll need more structure. But that’s a problem for a different series.
Sprint three: confidence
By sprint three, the rhythm is second nature.
Monday morning: sprint planning, Example Mapping the tricky stories, sprint goal written on a card above the story map. Daily standups: four minutes, blockers surfaced, on with the day. Friday: demo to the whole team, update the chart.
Sprint three goal: Ship delivery logistics and hit 50 subscribers.
The team completes nine of ten stories. The one they don’t finish is a nice-to-have that they deliberately dropped mid-sprint when a more important bug came in from pilot subscribers. That’s a good sign – the team is making trade-offs consciously instead of scrambling.
By the end of sprint three, the subscription flow works end to end. The farm portal is live and three farms are submitting availability weekly. Maya’s matching tool produces a packing list each Tuesday that the warehouse team follows. The first deliveries go out on Thursday.
Sam reports 38 pilot subscribers. The chart shows them slightly ahead of pace.
More importantly, the team has confidence. Not the week-one confidence that came from shipping fast and hoping for the best. Real confidence, grounded in data. They can see what they’ve built, what’s left, and whether the pace is enough. The chart says yes. The sprint reviews confirm it every two weeks.
Tom says something in the 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.”
What makes this work at five-person scale
Big organisations run sprints with dedicated Scrum Masters, Product Owners, elaborate ceremonies, multi-team synchronisation, and tracking tools that cost more than the GreenBox team’s entire AWS bill. None of that is what the GreenBox team is doing.
Here’s what the team’s sprint practice actually looks like:
Sprint planning: One hour, Monday morning. Whole team. Pick a goal, pick stories, Example Map the complicated ones. No story points. No planning poker. Just “these are the stories, does this feel like two weeks’ worth of work?”
Lee is deliberately avoiding formal estimation. “At five people, you don’t need story points. You need a conversation. If three developers look at a sprint backlog and say ‘yeah, that’s about right,’ that’s your estimate. If someone says ‘that’s too much,’ you take something out. The accuracy of a gut-feel estimate at this scale is indistinguishable from the accuracy of two hours of planning poker – and it costs nothing.”
The team will need more structured estimation later, when the board asks “how long will the Brisbane expansion take?” and when two squads need to coordinate dependencies across quarters. But at five people with one goal and one backlog, gut feel is the right tool.
Daily standup: Fifteen minutes max, usually five. If someone can’t make it, they post their update in Slack. It’s a blocker detector, not a status report.
Sprint review: Thirty minutes, Friday afternoon. Demo working software. Whole team watches, including Maya and Sam. Feedback goes straight onto the board for next sprint.
Retrospective: Every other sprint – so once a month. Lee facilitates, using the same five-stage format he introduced in the first retro: set the stage, gather data, generate insights, decide what to do, close with appreciations. Thirty minutes. The retro is the feedback loop for the sprint layer – it’s how the team learns whether their sprint rhythm is working and adjusts it. Without it, bad habits calcify. With it, the team evolves.
Progress tracking: Two numbers on a whiteboard. Stories done. Subscribers gained.
That’s it. The total ceremony overhead is about three hours per fortnight, spread across the team. For that investment, the team gets shared visibility into what they’re building, early detection of blockers, regular feedback from non-developers, and a clear picture of whether they’re going to hit the deadline.
If three hours per fortnight feels like too much process, consider the alternative: Tom building a subscription system on wrong assumptions for three weeks, Jas designing a feature Maya didn’t want, Priya blocked for a day on something Tom could have fixed in twenty minutes. The “no process” approach cost the team four weeks in the first month. The sprint cadence costs three hours per fortnight and prevents that from happening again.
The payoff
By the end of sprint four – week twelve – the GreenBox team has shipped the subscription flow, the farm portal, the matching tool, basic delivery logistics, a pause-and-resume feature, and a referral programme that Sam designed and Jas built.
The subscriber count on the whiteboard: 214.
They did it. Not comfortably – there was a rough patch in sprint three 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 week in sprint four where growth stalled and Maya stayed up until midnight emailing every contact she had. But the sprint rhythm gave them the one thing they didn’t have in the first four weeks: visibility. They could see the problem coming, adjust, and respond – instead of discovering at week eleven that they were behind.
The sprint cadence didn’t build the product. The team built the product. The cadence gave them a rhythm to build inside – a structure that turned individual effort into collective progress, and turned a vague deadline into a series of concrete, two-week commitments they could actually track.
What the sprint can’t tell you
The sprint cadence tells the team what they’re building and whether they’re on pace. But it doesn’t tell them whether the code they’re shipping is correct – whether the features do what Maya and the team agreed on, or whether the implementation matches the examples.
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 Example Maps gave the team concrete scenarios – context, action, outcome – and the sprint cadence gave them a rhythm. What they’re missing is the bridge between “cards on a table” and “working, verified software.”
The gap between understanding and implementation. That’s next (coming 5 May).