Resource Allocation Template

Why most resource allocation templates stop being accurate

Allocation boards fail in a specific way: they describe an intention rather than a fact, and the gap between the two only shows up when someone's already overcommitted.

Allocation lives in a spreadsheet updated weekly. By Tuesday it's describing last Friday's plan, and a new urgent request gets added to someone's row without anyone checking what else is already there.

Capacity is planned against headcount, not what people are actually carrying. A cell that says "80%" is an estimate typed in once and rarely revisited. Nobody can say whether it's still true, or was ever accurate.

There's no signal when someone is over capacity until they say so themselves. By the time it's raised out loud, the overcommitment has usually been true for a week or more, and something's already slipping quietly.

Assignment and actual work drift apart. A spreadsheet says a person is on a project; the tasks they're actually spending their day on are three unrelated fires that never made it onto anyone's plan. The plan and the person's real week stop describing the same thing.

Each of these has the same shape: a document that describes an intention, disconnected from a board that shows what's actually happening. Closing that gap doesn't need cleverness. It needs the plan and the work to live in the same place, updated by the same actions.

What this template is not

There's no optimizer here guessing the ideal assignment. This template relies on two plain mechanisms, a WIP limit on each person's column, and hours logged against the tasks they're actually doing, and nothing more sophisticated than that. Together they make overcommitment visible instead of estimated, but the decision about who takes what still belongs to whoever's running the board, not to an algorithm. If a tool promises to auto-balance workload across a team for you, this isn't that. What it gives you instead is an honest, current picture: who's full, who has room, and what each person actually logged their hours against last week, which turns out to be most of what the decision needs anyway.

What a reassignment looks like on the board

A hotfix request comes in for Priya, who's already at her limit of three. Instead of getting added as a fourth item, it sits against her column as an over-capacity flag, visible to whoever's managing the board, not buried in a message she'll see eventually. The manager looks at what she's carrying: a checkout bug fix, a payments code review, and a lower-priority task that can wait. That third item moves to unassigned, the hotfix takes its place, and the reason for the swap gets a line on the reassignment log: "moved to make room for payments hotfix, resume after." Nothing here required a formula. It required the load being visible enough that the decision took thirty seconds instead of a fire started by nobody noticing until Priya raised it herself, two days late.

How to use it

1. 01Build one column per person, or per small team. Set the WIP limit at genuine capacity: what they can actually carry in a normal week, not an aspirational number.
2. 02Keep new work in unassigned until someone actively pulls it or is assigned to it. That moment is the record of the decision, not a mention in a standup.
3. 03Log hours daily, even roughly. The point is a trail over time, not perfect accounting down to the minute.
4. 04When someone's column is full, treat a new request as a decision. Bump something out, add capacity, or say no. Don't just add it on top.
5. 05Write a line on the reassignment log whenever work moves between people. It's the difference between a swap that made sense at the time and one nobody can explain a month later.
6. 06Review the over-capacity signal weekly, not only after someone raises it themselves. By then it's usually been true for a while.

The mechanism is not proprietary. A WIP limit per person and an hours log will do the same job in any tool that supports both. It's written down here because most allocation spreadsheets have neither, which is exactly why they go stale within a couple of weeks of being built. What changes on ShipSprint specifically is how little the honesty costs: a five-second log per task is cheap enough that people actually keep doing it past the first week, which is the part every spreadsheet version of this quietly depends on and rarely gets.