Sprint 4 Retro: When Construction Becomes Convergence

Sprint 4 of Fizzics was supposed to be straightforward. Six stories: Game Center leaderboard, ad integration, and four art asset categories. The game was playable. The architecture was validated. All I needed to do was dress it up and plug in the platform SDKs.

I planned 30 tasks. I delivered 105.

Two of the six original stories never got started. And yet, the sprint was the most productive of the entire project. Something was wrong with how I'd planned it — not how I'd executed it.

The Plan vs. Reality

Here's what Sprints 1–3 looked like: pick 4–6 stories, build them in relative isolation, commit, move on. Each story mapped to one system. Beaker container. Blob physics. Merge detection. Scoring. Clean lines, predictable scope.

Sprint 4's plan followed the same pattern. Six stories, six systems. Game Center is a system. Ads is a system. Art assets are... well, assets. Import them, wire them, ship.

Here's what actually happened on Day 1: I validated the iOS build pipeline, discovered the VFX system needed a complete rewrite (1-layer → 5-layer compound explosions), built a custom SDF shader for tier indicators, imported $10 worth of UI sprites, and realized the entire UI needed architectural work — not just new textures, but new scripts, animation systems, and interaction patterns.

By Day 2, I'd found that overflow detection had never been wired up (the function existed but was never called), the Game Over panel had an inactive-GameObject listener bug that prevented it from ever showing, 11 tests were silently failing, and the event system would silently swallow errors if any listener threw an exception. One playthrough. All of that.

By Day 3, playtesting revealed the difficulty curve was fundamentally broken. Four merge tiers created a detonation every 24 drops — routine, not exciting. The beaker was too wide. Starting with three colors was overwhelming. I spent a session researching Suika Game (11 tiers), 2048 (logarithmic scaling), and Block Blast (spatial pressure), then redesigned the entire progression to six tiers with exponential scoring.

The sprint ended with 18 of 21 Must Have stories complete across the entire project, 208 passing tests, a full UI system, spectacular VFX, and a game that actually felt good to play. But Game Center and ads? Not started.

Three Sprint Types

The retro surfaced a pattern I hadn't named before. Not all sprints are the same, and planning them identically is why some sprints feel impossibly bloated while others glide through cleanly.

Construction sprints build new systems in relative isolation. Each story maps to a distinct system. You can estimate with reasonable accuracy because the scope is well-defined and the dependencies are minimal. Sprints 1–3 were construction.

Convergence sprints are the first time independently-built systems have to work together as a shippable product. This is where integration bugs surface, design assumptions get tested against reality, and "swap the placeholder art" turns out to mean "build the art infrastructure." Sprint 4 was convergence, planned as construction.

Polish sprints refine a working product. Tuning feel, fixing edge cases, improving visuals. The scope is defined by feel-targets, not feature lists.

The ratio tells the story. In construction sprints, planned-to-actual task count was roughly 1:1. In Sprint 4 (convergence), it was 1:3.5. Thirty planned tasks became 105 actual tasks.

The pattern is consistent: the sprint immediately after the walking skeleton becomes functional is almost always a convergence sprint. It's the first time anyone plays the whole thing, and the whole thing has opinions about what's missing.

The First Full Playthrough

Every major bug in Sprint 4 was discovered during the first time I actually played the game end-to-end. Not tested — played. Not debugging with breakpoints — tapping buttons and watching what happened.

Overflow detection was dead because the system worked fine in isolation. The overflow function existed, it was tested, the test passed. But nobody had ever called CheckOverflow() from the game loop. The function was a beautifully tested corpse.

The Game Over panel was broken because GameOverController.Awake() deactivated its own panel (standard Unity pattern for UI), which meant it couldn't receive the event that was supposed to reactivate it. The event system worked. The panel worked. The combination didn't.

The difficulty curve was too shallow because four merge tiers and a generous beaker meant the blob cap hit before overflow ever triggered naturally. The systems were all correct. The design was wrong. And the design was only wrong in the context of all systems running together.

Unit tests verify that individual pieces work. Integration tests verify that pieces connect. But a first full playthrough verifies that the product makes sense. It's a different category of signal, and it's free — you just have to actually do it.

What Changed in the Playbook

Retros that don't change anything are theater. Here's what actually changed:

Sprint Type Classification. The project plan step now asks you to label each sprint as Construction, Convergence, or Polish. Different types get different planning approaches. Convergence sprints budget 40% for discovered work and include integration testing as explicit tasks, not afterthoughts.

First Full Playthrough milestone. Convergence sprints now include a structured "play the whole thing" session early in the sprint, before polish begins. Log findings into three buckets: Broken (doesn't work), Wrong (works but incorrect), Missing (design assumed it exists). Then re-plan the sprint with the discovered work included.

Session boundary logging. Multi-session sprints now log a 3-line summary at each session boundary: what was done, what was discovered, what's next. Number sessions sequentially instead of mapping to calendar days.

Discovered work audit. The retro template now includes a section for convergence sprints that tracks planned-to-actual task ratio. A ratio above 2.0 means the sprint was planned as construction but was actually convergence.

Design sanity check. Before starting a sprint, ask: "Does the current design hold up? Are the numbers right?" A five-minute question like "are four tiers enough depth for an endless game?" could have prevented a multi-day rebalance.

Design specs for large stories. The UI pass succeeded with zero rework because I wrote a 27-step spec before touching code. The VFX system took three iterations because I just started building. Both approaches have their place, but large stories benefit from upfront design.

Could We Have Caught It Earlier?

Some of it, yes. Dead overflow detection would have been caught by a "can you reach Game Over?" integration test. The inactive-GameObject bug is a known Unity gotcha. The event system should have had try/catch from the architecture phase. A checklist of "known platform gotchas" before integration would have surfaced these in minutes instead of hours.

Some of it, no. The difficulty curve was only wrong in the context of the complete game. You can't evaluate "is this fun?" until you can play it. The VFX needing three iterations is normal for visual work — you can't spec "looks spectacular" into existence. Art direction pivoting from procedural to AI-generated was a quality decision that only makes sense after seeing both options.

The playbook now distinguishes between these categories. Predictable integration issues get checklists. Design validation gets playtesting rituals. Visual iteration gets time budgets (2× the initial estimate for VFX work). Different failure modes get different prevention mechanisms.

The Scoreboard

Sprint 4 by the numbers:

The delivery was excellent. The planning was the problem. And now the planning is better.

That's the point of a retro. Not to feel good about what shipped. Not to wallow in what didn't. To change the process so the next sprint starts from a better place than the last one.