Project Management for DevOps Projects

Incidents and upgrades are both real work, and they compete

DevOps work comes in two shapes, and they don't take turns. There's the planned kind, a Kubernetes upgrade, a cost-optimization pass, migrating a CI pipeline to a new runner, and the unplanned kind, which shows up as a page in the middle of the night and swallows the sprint regardless of what was scheduled around it.

The usual failure mode is planning as though the second kind won't happen. The sprint gets loaded with upgrade work at full capacity, the first incident of the week blows the plan, and every plan after quietly discounts itself a little further, until the roadmap for infrastructure work isn't believed by anyone, including whoever wrote it.

The less obvious failure is what happens to the incident work itself once the fire is out. A postmortem produces action items, patch the root cause, add a check, update a runbook, and those items compete with planned work for space that was never allocated to them, so they either get done in an ad-hoc rush or quietly never get done at all.

ShipSprint doesn't monitor anything and has no alerting or infrastructure integration. It's not what pages someone at 2am, and it never will be. What it gives the fallout from that page is somewhere honest to land: a triage inbox with WIP limits, so incident-driven work and planned work sit on the same board without one silently eating the other's capacity.

Why the postmortem's action items are the part that gets lost

The incident itself gets attention by default: pages go out, people join a call, it gets fixed. The action items that come out of the retro afterward get attention by willpower alone, competing against whatever was already planned for the sprint, with nobody's job specifically being to make sure they land.

Writing the postmortem to a wiki page and turning each action item into a task the same day closes that gap without inventing new process. The task sits in the same triage inbox as everything else, subject to the same WIP limits, which means it either gets prioritized honestly against planned work or it gets deferred honestly, not forgotten by accident three sprints later when the same root cause pages someone again. That's the actual payoff of running incident follow-up through ShipSprint rather than a running doc: the action item competes for capacity the same way real work does, instead of losing by default.

What keeps planned work from losing every time

• Route incident follow-up into the same triage inbox as planned requests, not a separate side channel that never gets reviewed against capacity
• Give the on-call or firefighting column its own WIP limit, so it doesn't silently absorb the whole board during a bad week
• Log postmortems as wiki pages and convert each action item into a task the day it's written, not the week it's remembered
• Let the forecast, not habit or optimism, decide whether next sprint's planned load needs trimming

One system for the team that keeps everything else running

DevOps work rarely stays inside one team's boundary, a migration needs sign-off from engineering leadership, a cost review needs finance, a security patch needs whoever owns compliance. Engineering, HR, marketing and operations each get their own templates on one subscription, so pulling in another function doesn't mean exporting a spreadsheet or explaining sprint terminology first.

It also connects to Claude and ChatGPT, so someone can ask "what infra work is at risk this sprint" in plain language without pulling an on-call engineer away from actual work to answer it.