Sprint planning

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• Wire billing webhook → plan quotas

  Stripe is the source of truth for plan changes.

  P23pt

• OAuth callback HMAC verification

  Sub-issues: signing key rotation, replay guard, tests.

  P15pt

• Migrate audit log to LISTEN/NOTIFY

  P22pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Issue moves to 'In review'

  Then

  Post the issue link to your #engineering Slack channel

• When

  Linked PR is merged

  Then

  Move the issue to 'Shipped' and add a 'released' label

• When

  Cycle ends

  Then

  Roll incomplete issues into the next cycle and notify owners

The column order on this board is an argument, not a decoration. Backlog and Todo are separated because the moment a team plans out of a single undifferentiated list, planning becomes re-reading the whole backlog every two weeks. In progress and In review carry soft WIP caps of five and three because the failure mode of a sprint board is not people working too slowly — it is eight issues open at once, each 80% finished, none shippable. The caps are soft on purpose: they warn, they do not block, because a hard block on a Friday afternoon just teaches people to lie to the board.

1. 1.Refill the backlog between cycles, never during one

   Backlog is the only column allowed to be messy. Groom it on a fixed day — the day before planning is the common choice — and grade each issue on whether someone who did not write it could start it. Anything that fails that test is not a backlog item yet; it is a research question, and it belongs in Todo only after someone has answered it.

2. 2.Commit scope once at planning, then stop adding

   At planning, pull issues from Backlog into Todo until the estimate total matches what the team actually finished last cycle, not what it hopes to finish. Once Todo is set, it is closed for the cycle. Mid-cycle arrivals go to Backlog with a note, and the only exception is a genuine production incident — which is a different board entirely.

3. 3.Respect the In progress cap of five

   The cap is per board, not per person, and that is the point: it forces the team to finish before it starts. When the badge goes amber, the correct move is to help someone move a card right, not to open a sixth. If the cap is chronically wrong for your team size, change the number in the list settings — do not ignore it, because a WIP cap everyone ignores is worse than no cap.

4. 4.Treat In review as a queue with an owner, not a status

   The cap of three exists because review is where sprint work goes to die. Give the column a daily glance and pull from the top, oldest first. If a card has been in review longer than a day, that is a conversation, not a nudge — the reviewer is either blocked, over-assigned, or unclear on the change.

5. 5.End the cycle honestly, then let rollover happen

   Do not close a cycle by dragging unfinished cards to Shipped. Let incomplete work roll into the next cycle so velocity history stays truthful; a burndown you have quietly edited is a burndown you cannot plan against. Spend the first ten minutes of the next planning session on what rolled over and why, before anyone pulls a new card.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• Your work is interrupt-driven. If more than roughly a third of a typical week arrives unplanned — support escalations, customer emergencies, on-call — a fixed two-week commitment will be wrong on day three, every time. A continuous-flow board with WIP caps and no cycle boundary is the honest shape for that team; keep the caps, drop the sprint.
• You are one to three people. Sprint ceremony has real overhead — planning, estimation, review, retro — and it pays for itself by coordinating people who cannot see each other's work. At three people around one table or one channel, the ceremony costs more than the coordination it buys.
• You do not estimate and do not intend to start. Half this board's value is the velocity history that makes next cycle's commitment realistic. Without estimates you get a kanban board with an arbitrary two-week fence around it, which adds a deadline without adding forecasting.
• The work is genuinely open-ended research. A spike whose output is 'we now know whether this is possible' does not fit a column called Shipped. Run those as timeboxed discovery issues on a separate board and let the sprint board hold only work with a definition of done.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• Linear

  Linear's cycles are the closest thing to this template in another tool, and they are more opinionated: cycles start and end automatically, incomplete issues roll forward without anyone deciding to, and the velocity graph is built in rather than assembled. The meaningful structural difference is per-column work-in-progress caps — Linear's model is deliberately status-based rather than column-limit-based, so the 'five in progress' constraint above is a team norm there rather than something the board itself displays.

  Where Linear is better: If your whole company is engineering and you want sprint mechanics to be invisible and automatic, Linear does this better with less configuration. Its keyboard-first interaction model and its opinionated defaults mean there is simply less for a team to get wrong, and its cycle automation needs no maintenance at all.

• Jira

  Jira models Scrum formally: sprints are objects with a goal, a commitment, and a closing ritual, and the reporting suite around them — burndown, sprint report, control chart, cumulative flow — is the most complete on the market. This template deliberately encodes a lighter version of the same loop: five lists and two caps rather than a scheme, a workflow, and a board configuration.

  Where Jira is better: If you need certified Scrum artifacts, cross-project portfolio rollup, or the audit depth that a regulated or large organization requires, Jira is genuinely the stronger tool and it is not close. Its reporting alone is deeper than anything this board produces, and at several hundred engineers that depth stops being overhead and starts being necessary.

• ClickUp

  ClickUp can build this board and considerably more — sprint points, burndown widgets, time tracking, and custom fields of nearly any type. The difference is where the opinion lives. This template ships five lists and two caps and expects you to change them; ClickUp ships a configuration surface and expects you to design the workflow yourself, which is more power and more decisions.

  Where ClickUp is better: If you need time tracking tied to sprint items, per-item custom fields with rich types, or a single tool spanning engineering, sales and client work with genuinely different schemas per space, ClickUp's breadth is a real advantage. Teams that want one tool to do everything usually find more of 'everything' there.