Sprint review format

✓ Pattern Easy cadence & flow

Review what compounds — product, skills, architecture, key changes — not how much code got finished.

The team friction The classic review walks completed items one by one. When a team plus agents ships far more, that turns into an output parade — people reporting how much they got done, where “finished” means code merged rather than value delivered. Attention drains on volume, and the things that actually compound — what the team learned, how its skills and architecture moved — get no airtime. The team reviews how busy it was, and never reviews whether it shipped anything that matters.

The pattern The team reshapes the review around what’s worth its collective attention: the product direction, the skills the team built or needs, the architecture as it now stands, and the key changes that matter. Demo the features genuinely worth seeing — a chosen few that move the product, not a tour of everything to prove effort. The test for the agenda is “does this repay a whole-team hour?”, not “did we do it?”

Why it works with AI Volume of shipped code is no longer a useful signal — agents inflate it, so reporting it all is noise (and rewarding it invites the token trap). What stays scarce and worth syncing is shared learning, direction, and the handful of changes that genuinely shift the product. Curating to those keeps the review about value delivered, not activity performed.

Watch-outs Don’t over-correct into killing demos — a real, working feature is often the clearest thing in the room; just pick the ones that matter to the people watching. And keep it honest: a review that only shows wins teaches the team nothing.

Related Trap: measuring AI adoption by tokens spent · Current-architecture workshop · Skill sharing