Project Management for Software Releases

The gap between claimed-done and actually-done

A sprint has some give in it. If three items don't get finished, they roll to next sprint and the world barely notices. A release doesn't have that give. The date arrives, marketing has scheduled the announcement, and whatever's actually mergeable at that moment is what ships, whether or not it matches what the board said a week earlier.

The specific risk isn't that work is late. It's that a board says something is done when what actually happened is a feature demoed fine in a local environment, or a fix that closed a ticket in someone's head before the pull request closed it in git. That gap is invisible right up until release day, when someone runs the actual build and finds three items that were "done" for two weeks are not, in fact, in the code that's about to ship.

Release management, done properly, is the discipline of closing that gap before it closes it for you, in front of a customer, on the day you told them to expect it.

It's worth naming what makes a release different from an ordinary sprint deliverable: a release is a single, indivisible event. You can't ship 80% of it and call it mostly successful the way you can call a sprint mostly successful. Either the cutover works or it doesn't, which is exactly why the gap between claimed and actual matters so much more here than it does on any other kind of deadline.

That all-or-nothing quality is also why release day tends to surface problems that a normal sprint review never would. A dependency between two "done" items that were never actually tested together is invisible right up until they both go live at once, a specific kind of failure that only a release, not a sprint, can produce.

Merged is a fact. "Done" in standup is an opinion.

The GitHub sync exists for exactly this gap. A branch opened against an item moves its card to in-progress; a merged pull request closes it. Nothing about that status comes from a person deciding to update it. It's a byproduct of the code actually landing, which means the release board only shows an item as ready when it's genuinely mergeable, not when someone believed it was.

That distinction matters most in the final days before a cutover, when the question stops being "how's the sprint going" and becomes "what, specifically, is in this build right now." A release built from a board that tracks merges answers that question directly. A release built from a board that tracks standup updates answers a slightly different, more optimistic question. On ShipSprint, that's the difference between a "done" column that's aspirational and one you'd actually stake a release on.

The forecast helps earlier than that: because it's calculated from measured velocity as sprints close, a release date under real pressure shows it in the projection weeks out, not the week of. That's the difference between quietly trimming scope on purpose and discovering the scope cut on release day itself.

Why "code complete" and "release ready" are different dates

It's tempting to treat the last commit before a release as the finish line, but code complete and release ready are two different milestones, and conflating them is one of the more common ways a team ends up cutting a release under more pressure than it needs to be.

Code complete means the features are merged. Release ready means they've been tested together, the release notes are written, the rollback plan exists, and someone has actually confirmed the build that's about to ship matches the one that was tested. That's a distinct piece of work, not a formality that happens automatically once the code lands.

Teams that treat these as two separate tracked milestones, with their own dates and their own checklist, tend to have calmer release days than teams that only track code complete and assume everything after it takes care of itself. The gap between the two is usually where the actual release-week chaos lives.

Coordinating a cutover across more than one team adds a third milestone worth tracking on its own: sequencing. If a database migration has to land before a service restarts, or one team's deploy has to precede another's, that order needs to be a checklist a specific person owns, not a shared understanding that turns out three different people understood three different ways at 2am.

The checklist a release actually needs

• Every item claimed as done is confirmed merged, not just marked complete by whoever was working on it
• A code freeze date set with enough runway before cutover to actually test what's frozen, not just declare it
• Release notes drafted from the closed items themselves, not written from memory the night before
• A named owner for the cutover step itself: who flips the switch, and who's on call if it needs flipping back

Most release-day fire drills trace back to one of these four being skipped, not to bad luck. Making them checklist items rather than assumptions is most of the fix.

Where this sits above a single sprint

A release usually gathers work from more than one sprint, and sometimes more than one team. The sprint-level mechanics underneath it are covered in the software development use case. This is the layer that sits above that: what has to be confirmed true before a collection of sprints becomes a thing you actually ship.

Every workspace is an isolated tenant with an admin audit log and JSON export on demand, relevant if your release process needs a compliance record; see the security page for the full detail.