Grooming Sprint 5: Turning the Backstop Into a Real Admin Experience

Sprint 4 (Auth II) closed today: social sign-in, password reset, account linking, seven issues shipped as seven pull requests. Same day, same session, I groomed the next sprint — Admin Experience — into its own milestone and seven more issues. No application code changed. That's twice in a row now that a sprint closed and the next one got scoped before any implementation started, and this one had a different kind of scoping problem than Auth II did.

The sprint that's partly already built

Auth II was greenfield — nothing existed yet to build on. Admin Experience isn't. Sprint 2, back in mug-club core, already shipped a real admin confirmation-audit screen and a bartender PIN issue/reset/deactivate API. So the actual scoping work this time wasn't "what needs to exist" — it was going back through the existing controllers to figure out honestly what's already there versus what just sounds like it should be, given the feature name.

That check turned up a specific, easy-to-miss gap: the PIN management API has existed since Sprint 2, admin-only, fully functional — and there has never been a single screen in front of it. An admin today could issue or reset a bartender's PIN only by hand-crafting an API call. Naming that gap precisely, rather than writing a vague "build user management" ticket, is what let the sprint sequence a User Management screen as mostly wiring rather than new design.

Generalizing instead of duplicating

The other piece the roadmap has always called "full data correction" — admin can edit any record, with a required reason and an audit trail. Sprint 2 already built exactly that shape once, for confirmations: a void endpoint, a required reason field, an audit row that never gets deleted. The temptation with a new sprint is to build that same pattern over again for beers and for accounts, three separate times, because each story's author is thinking about their own entity.

Instead, the first story in this sprint pulls that shape out into a shared AdminAudit trail — one audit concept, reusable across entity types — and everything else builds on top of it rather than beside it. The existing confirmation audit stays exactly as it is; nothing gets migrated or disturbed. It's the same instinct as Auth II's email-sender story: when you can see a second consumer coming, build the shared piece once instead of twice.

Scoping out what doesn't exist yet

The roadmap's language for this epic includes "moderate the social layer — display names, feed items." It would have been easy to write that as a story just because it's on the list. But there's no social layer in the app yet — no feed, no display names, nothing to moderate — that's a different, later epic. Scoping it into this sprint would have meant writing a ticket for a screen with nothing behind it. It stayed off the board, with a note explaining why, rather than getting ticketed just because a planning doc mentioned it once.

The PM angle

Two groomings in one week look similar from the outside — issues, a milestone, dependency order — but the actual thinking underneath was different each time. Auth II was almost entirely about sequencing new work correctly. This one was about auditing existing work honestly before adding to it: what already has an API but no UI, what pattern already exists and just needs generalizing, and what's on the wishlist but genuinely isn't in scope yet. Skipping that audit doesn't cause a dramatic failure — it causes quiet waste, a rebuilt PIN endpoint here, a moderation screen for a feature that doesn't exist there. Cheap to catch during grooming, easy to miss once you're heads-down writing code.

Where the project stands