DevOps Project Template
Not a one-time migration plan. A running board for the infrastructure work that never really finishes: postmortem follow-ups, on-call fallout and planned changes.
Every card traces back to either a postmortem or a planned change: nothing lands here without a reason attached.
Why most infra boards drift away from what's actually running
Infrastructure work doesn't stop after a launch. Incidents produce follow-up actions, on-call shifts surface things that need fixing, and infra-as-code keeps changing under everything else, week after week, with no natural finish line. A project plan built for a task with a start and an end doesn't fit that shape, and teams that try to force it into one usually end up with a board that describes last quarter, not this one. A board for this kind of work fails in specific ways that a one-off project plan doesn't.
Postmortem actions get written down once and never tracked. A retro produces a list of "we should really fix this," it goes into the meeting notes, and six months later half of it hasn't happened because nothing put it somewhere anyone revisits.
On-call findings stay with whoever was on call. Someone notices a flaky check or a credential that shouldn't still work during a 2am page, mentally files it under "deal with later," and later doesn't arrive because there's no shared place it landed.
Infra changes happen with no record of why. A Terraform change raises a limit or swaps a config, it merges, and a year later nobody remembers whether it was a deliberate decision or a quick fix that was supposed to be temporary.
The result of all three, together, is a gap between the board and the systems it's supposed to represent. Someone looks at the board expecting to see the state of the infrastructure and instead sees a rough sketch of it, several weeks out of date, missing exactly the follow-up items that matter most.
This is a template for ongoing infrastructure work specifically, not a one-time migration plan. If you're moving a whole system to new infrastructure once, that's a different kind of project with a start and an end. This board is for the work that keeps arriving after everything is already running.
The structure, and why each part is there
Every action item from an incident review, and every "we should fix this" that comes out of an on-call shift, lands in the same place, not scattered across meeting notes and whoever remembers to raise it. It sits there, visible, until someone plans it in.
A card is either tied to a specific postmortem or marked as a planned change, with a line explaining why. Undocumented infra work, the kind nobody can explain a year later, doesn't get a quiet way onto this board. That reasoning lives in ShipSprint's built-in wiki with full page history, so "why did we do it this way" has an answer even after the person who made the call has moved teams.
Infra changes carry more blast radius than most work, and a low WIP limit means changes get reviewed and verified one or two at a time instead of several landing simultaneously with nobody watching all of them. It's a small constraint that does a lot of quiet work: it's genuinely harder to lose track of a change when only two can be in flight at once.
A change reaching this column means someone confirmed the thing it was meant to fix is actually fixed, not just that the pull request went in. Merging and verifying are treated as two different steps.
Branches move cards, merged pull requests close them, and cycle-time analytics show how long infra changes actually take from opened to verified, often a useful number to have on hand at the next postmortem.
The built-in wiki holds the reasoning behind a change, why this config, why this limit, why now, with page history, so the answer to "why did we do it this way" doesn't depend on who's still on the team.
ShipSprint connects to Claude and ChatGPT, so a question like "what changed in the checkout service's infra last month" can be answered from the board and wiki directly, in plain language, instead of scrolling through a commit log guessing at intent.
How to use it
- 01Start a workspace. It opens with a sample project already on the board, so the flow from follow-up to verified is visible before real incidents feed into it. Free for up to five people, permanently.
- 02Turn every postmortem action item into a card the same day. Notes in a doc that never gets reopened are where most follow-up work actually dies. The gap between "we discussed it" and "it's on the board" is where most of these actions are lost for good.
- 03Give on-call a fast way to file what they noticed. It doesn't need to be fully written up at 2am. A rough card that gets fleshed out later beats nothing landing on the board at all.
- 04Keep In progress capped low. Two infra changes deployed and verified beats five half-landed changes nobody's confident about.
- 05Write the "why" on the card before merging, not after someone asks. A sentence linking the change to its postmortem or planned reason takes less time than reconstructing it later.
The board doesn't run your infrastructure or replace whatever monitors it. It's where the human follow-up work lives, so a postmortem's action items have somewhere to go besides a shared doc nobody reopens after the meeting ends.
- Postmortem actions need a home that outlives the meeting they came from
- Merged and verified are different states, so treat them as different columns
- This is for ongoing infra work, not a one-time migration; those need a different plan
Common questions
No. A migration is a one-time move with a defined end point, which is a different kind of plan. This template is for the ongoing infrastructure work that continues after everything's already running: incident follow-ups, on-call action items and planned infra changes.
No. This board tracks the follow-up work that comes out of an incident, not the incident response itself. Run the incident wherever you already do; when it's resolved, the actions it produced get cards here.
A branch tied to a card moves it as work progresses, and a merged pull request closes it. Burndown and cycle-time analytics are generated from that activity, which is useful here specifically because infra change lead time is a number worth tracking on its own.
It stays visible in the backlog rather than disappearing, which is the point. A stale item you can see is a decision waiting to be made (fix it, or decide it's not worth fixing and say so), while a stale item nobody can see just quietly never happens.
Yes. Each service or team can run its own project with this same column structure, or share one board if the on-call rotation and infra ownership overlap enough that separating them would just mean duplicating cards.
Yes. All templates are included on the Free plan, which covers up to five users and two projects and doesn't expire. See pricing for larger teams.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required