Software Development Project Template

Why most dev boards drift from the sprint

Most teams that adopt a board do it for visibility: a shared answer to "where does this stand" without a status meeting. That only holds if the board keeps up with the repo on its own. The moment it needs a human to manually keep it honest, it starts falling behind, usually within the first sprint or two, and nobody notices until a stakeholder asks about something the board says is still in progress and turns out to have shipped two weeks ago.

A dev board usually starts accurate and stops being accurate within a couple of sprints, for reasons that have nothing to do with the team's discipline. The team didn't get sloppy. The board was never built to survive the gap between what's tracked and what's actually true in the repo, and that gap widens every day nobody closes it by hand.

The board and the repo disagree. A card says "in progress" because someone dragged it there on Monday. By Thursday the branch is merged and the card hasn't moved, because moving it is a second step nobody remembers to do. This template links cards to branches and pull requests directly, so the card's column reflects what the repo actually shows.

Sizing is either absent or theatre. Story points only mean something if they're checked against how long things actually took. Without that feedback loop, planning is a guess dressed up as a number.

The sprint column has no ceiling. Anyone can pull anything into it at any time, so "this sprint" quietly becomes "everything we might do eventually," and forecasts built on it are fiction.

Review becomes an unlisted stage. Work that's technically finished but waiting on a reviewer doesn't show up anywhere obvious, so it's easy to lose track of how much is actually done versus how much just looks done because the branch exists. A board that only has "in progress" and "done" hides the exact stage where most delay actually happens.

This template is deliberately unopinionated about process. It doesn't assume Scrum, Kanban, or anything with a name. What it assumes is that a card should represent one identifiable unit of work, that work in progress should be capped, and that the board should be able to answer "what's actually happening in this repo right now" without anyone opening a status meeting to find out. Connect the repo once and that question stops needing a meeting at all: the branch and PR linkage is what keeps the board honest without anyone dragging a card by hand.

How to use it

1. 01Connect the repo first. Card movement only tracks reality once branches and pull requests are linked, so do this before the first sprint, not after cards have already drifted.
2. 02Size the backlog before you plan a sprint. An unsized backlog can't produce a real capacity limit, only a guessed one.
3. 03Let the first two sprints set your velocity. Forecasts before that are informed guesses; after that they're calculated from what the team actually closed.
4. 04Cap the sprint column at that velocity, not at what the team hopes to do this time.
5. 05Review the burndown mid-sprint, not at the retro. By the retro it's a history lesson, not a course correction.
6. 06Keep the review column capped too, not just the sprint column. A team that can start work faster than it can review it just moves the bottleneck one step to the right.

None of this requires a particular methodology. Teams running two-week sprints, teams running continuous flow with no sprint boundary at all, and teams somewhere in between can all use the same four columns. The point ceiling and the branch linkage do the actual work, and the labels around them are just vocabulary.

Time logging sits on this board too, next to whatever card someone just finished. It takes about five seconds and doesn't require switching to a separate timesheet tool. Most teams turn it on after the first sprint or two, once the board itself is trusted enough that logging against it feels worthwhile rather than performative.