Website work arrives from everywhere
A new solution page from sales. A pricing change from product. An SEO fix that has been waiting three weeks. A homepage test somebody agreed to in a meeting nobody wrote down. None of it arrives through one door, and none of it arrives with a size attached.
It fails the same way. Everything is verbally agreed and nothing is visibly queued, so every request looks like it should start today, and the honest answer to "when can you do this" is a shrug with a tone of voice.
The intake column is how you get to say no
The board opens with a column called requests. Anything asked for lands there first, with a type, a rough size and one line about what it is. Nothing moves out of it until we agree on the scope.
That column does more work than the rest of the board combined. A request sitting in intake sits there until somebody decides. Without it, saying no means saying no to a person. With it, the conversation moves to the queue: this is what is in front of it, so tell me what it goes ahead of.
What a card carries
A card stays small. It holds a title written as the outcome, a type, a size, an owner, the workstream it belongs to, a link to the artifact, and a status. Seven fields, and each one earns its place by answering a question somebody asks out loud.
Type matters more than it looks. A new page, a change to an existing page, a technical fix and a piece of research move at different speeds and carry different risk. A board that treats them identically will happily schedule a three-week research task beside a half-hour copy change. Type is what makes a quarter legible: eleven cards is noise, while eight technical fixes and three new pages is a shape somebody can react to. A typical quarter carried roughly 10 to 15 cards, over half of them technical fixes.
Anything longer than one line belongs in the document the card links to. Keeping the card thin means whoever owns the work can rethink it without touching the board, and the board stays scannable at the size a person reads it.
Two views, one set of records
I render the same cards twice. Both views group and filter one set of records, so nobody maintains either one. One groups by status, the other by workstream. Move a card and both update.
The sprint board reads left to right: requests, scheduled, in sprint, then out through the release pipeline. It answers the question the people building things have, which is what am I doing this week and what is behind it.
The quarter map is a grid. Rows are workstreams such as homepage and conversion, solution pages, agent pages, feature pages, SEO and infrastructure. Columns are now, next and later. Each cell shows a state. I draw proposed work differently from committed work so the difference survives a glance.
That second view answers a different question: where is this line of work going, and what we committed to. The CMO and the regional leads ask that one, and it replaced a monthly slide. Nobody doing the work asks it while they are doing the work.
Most teams maintain these separately, and they drift
Usually that means a task tracker for the team and a slide for leadership. They start aligned. Then a card moves, the slide does not, and within a month the roadmap you present upward describes work that stopped two weeks ago.
Moving a card is the only update, and nothing else needs remembering.
Every card points at the thing itself
Cards carry a link to the artifact: the staging URL for a page in progress, the research doc behind a proposal, the workplan for an SEO stream. Status is a URL you can open.
This kills the most meetings. "How is the homepage test going" has an answer that is a link to the staged version, so the person asking can look at it instead of scheduling twenty minutes to be told about it.
Why there are no dates on the cards
Cards carry a size, roughly S, M or L, and no dates below the sprint level. Dates on individual pieces of website work are fiction, and everyone treats them as fiction, which makes the whole board less trustworthy.
Sizes do the job dates were supposed to do. Three large items in one sprint is visibly wrong before the sprint starts.
How the sizes get agreed
S, M and L only work if two people mean the same thing by them, so I anchor them to examples. A small is a change inside an existing template. A medium is a page that needs new copy on a layout that already exists. A large is anything needing a new layout, a new component, or a decision from somebody outside the team.
Examples survive turnover in a way hours never do. Somebody new can size their first card on their first day by comparing it to work already sitting on the board, and the sizes stay comparable across quarters even as the people doing the work change.
The release log is the memory
Shipped work drops into a dated log with the release it went out in. It takes seconds to maintain and answers the question everyone keeps asking: when did this change, and what else went out with it.
It turns the board into a record of what a team produced over a quarter. A list of what it plans to produce next tells you less.
Where this breaks
Three failure modes, all of them mine.
A card sits in the in-sprint column across three sprints. It is usually a large that should have been split, and it hides because the board renders it as active work. Once a week I look at how long each card has sat where it is, and they surface.
Intake turns into a graveyard. Requests land, nothing is ever declined, and the column grows until people stop reading it. By then the board has stopped saying no, and saying no is what the column is for.
The quarter map grows rows. Every new workstream feels justified the day it arrives, and a grid with eleven rows tells a reader nothing at a glance. Six is the most I have managed to keep legible.
What it costs
The board is only worth having if it is true, and staying true costs a few minutes at the end of each working session. I move what moved and log what shipped. Anything that arrived goes into intake.
That is the whole discipline. It costs a few minutes a day, and it replaced a weekly status round that took about an hour with the six to eight people on the board, across design, front end, SEO and content.