Your Release Notes Are Fiction (And How to Fix That)
Most release notes describe what was planned, not what shipped. Kwilio Projects refuses to close a release while work is still open — here's why that matters.
Open the last release your team shipped and read its notes. Then open the repository and read what actually merged before the tag was cut. In most teams, those two documents disagree — and the release notes are the one that's wrong.
This isn't sloppiness. It's what happens when a release is a plan that never gets corrected.
How Release Notes Drift From Reality
A sprint gets planned. Twenty tasks go into it. On the last day, fourteen are done, four are nearly done, and two haven't been started. The release goes out anyway, because the date was the point.
Now someone has to write the notes. The fastest thing to do is describe the sprint — the twenty tasks that were supposed to land. The four "nearly done" ones feel done enough to mention. The two untouched ones quietly disappear from the document without ever being marked as anything.
Three weeks later a customer asks why the feature in the release notes doesn't work. Nobody can reconstruct what happened, because the only written record says it shipped.
The Fix Is Structural, Not Disciplinary
You can't solve this by asking people to be more careful when writing notes. The pressure to describe the plan rather than the outcome arrives exactly when everyone is tired and the release is already late.
What works is making the honest path the easy one — having the tool refuse to record a fiction in the first place.
How Kwilio Projects Handles It
A sprint and a version are the same entity. Not a sprint that "contains" a version, or a milestone loosely associated with a tag. One dated bundle of work belonging to one project. Name it "Sprint 12" or "v2.1" — it's the same object either way, so there's nothing to keep in sync.
Shipping is guarded. A release refuses to close while tasks are still open. You get two honest options: finish the work, or move the open work out of the release. Either way, what's left in the release is what actually shipped.
The plan stays visible next to the outcome. The date you planned sits beside the date you shipped. A release that slipped by three weeks still says so a year later, which is the only way anyone learns anything about estimating.
A task belongs to at most one release. Adding it to a sprint takes it out of the last one, so work never gets counted twice across two sets of notes.
Deleting a release unschedules its tasks — it never deletes work. Cancelling a sprint shouldn't cost you the tasks in it.
Reconciling Against the Code
"Done" on a board and "merged" in a repository are two separate claims about the same work, and they disagree more often than anyone likes to admit. A task marked done whose branch never merged is a bug waiting to be reported. A merged branch whose task is still open is a board nobody trusts.
Name a branch WEB-14-fix-login and it attaches itself to task 14, with its commits and pull requests — nothing to click. When it's time to draft release notes, Kwilio Projects counts work as shipped if either signal is true, and every disagreement comes back to you as a finding rather than being quietly resolved in favour of whichever source the tool happened to trust.
That last part matters. A tool that silently picks a winner between two contradictory facts has just moved the fiction one layer down, where you can't see it.
Why This Runs on Your Desktop
Kwilio Projects is a native app for macOS and Windows — not a browser tab pretending to be one. It's sized for a desktop window rather than a page, which is about a third more on screen at once. Boards drag without lag, filters narrow what's already loaded, and unsaved edits to a task survive a crash, a minimise, or an update relaunch.
Get Kwilio Projects
Free for 14 days, no card, every feature. Updates install themselves.
Download for macOS Download for WindowsAvailable for macOS and Windows. Stop shipping release notes you can't defend.