If someone walked up to your team and asked “What are you all working on right now?”, the project board should answer that question in under 30 seconds. No meetings, no Slack threads, no “let me pull up my notes.”
The board is the single source of truth for the project. It tells the team and its stakeholders four things:
- What is next?
- What’s done?
- Who’s working on what?
- How much do we have left?
When the board is healthy, most “sync” conversations become unnecessary. When it’s not, you’ll notice the symptoms quickly: people asking for status updates, engineers unsure what to pick up next, and stakeholders who feel out of the loop no matter how many meetings you schedule.
Backlog: What is next?#
The backlog is a single, prioritized list. One list. Not a list per engineer, not a list per feature area, not a “frontend backlog” and a “backend backlog.” One list, ordered top to bottom by priority.
This sounds simple, but most teams don’t actually do it. They end up with tickets scattered across multiple views, labels acting as pseudo-backlogs, or a backlog so long that nobody reads past the first five items.
A single prioritized backlog solves several problems at once:
- Alignment happens automatically. If the stakeholder’s top priority is at the top of the list, the team is working on it. No alignment meeting needed.
- Priority changes are cheap. Stakeholder changes their mind? Move the ticket up or down. The team sees the change next time they look at the board.
- “What should I work on next?” answers itself. Grab the top unassigned ticket. Done.
- The team focuses together. Instead of five engineers working on five unrelated things, you get natural collaboration on the same goal. People pair up, unblock each other, and finish work faster.
- Standups get shorter. When everyone can see the board, you don’t need to narrate your status. The standup becomes about blockers and adjustments, not recaps.
What makes a bad backlog?#
If your backlog has more than two weeks of work in it, it’s too long. Nobody is reading ticket #47. Anything beyond the near-term horizon belongs in the icebox (more on that below), not cluttering the backlog.
If tickets in your backlog don’t have clear acceptance criteria, they’re not ready. An engineer should be able to pick up the top ticket and start working without needing a 20-minute conversation first. If they can’t, the ticket needs more refinement before it earns a spot in the backlog.
In Progress: Who’s working on what?#
Each person should be assigned to exactly one ticket at a time. Not two. Not “one main thing and a small side thing.” One.
This feels restrictive, but it solves a problem that every team hits eventually: context switching. When someone is juggling three tickets, none of them are getting their full attention. Progress on all three slows down, and the board looks like everything is “in progress” but nothing is actually moving.
team size / 2. On a team of 4, if you see more than 2 tickets in the “In Progress” column, something is off. Either someone is multitasking, or people aren’t pairing up.When someone gets blocked on their ticket, they shouldn’t just pick up a second one and leave the first sitting in limbo. They should move the blocked ticket back to the top of the backlog, unassign themselves, and add a # Blocked section at the top of the ticket explaining why it’s stuck. Then they grab the next thing.
This keeps the board honest. If a ticket is in “In Progress,” someone is actively working on it right now. If it’s blocked, it’s visible in the backlog with an explanation, not hiding in a column where everyone assumes someone is on it.
Done: What’s done?#
“Done” is the most abused column on any project board.
The test is simple: when a ticket is in “Done,” can the team stop thinking about it entirely? If the answer is “well, yes, but we still need to test on prod” or “yes, but we haven’t told the customer yet,” then it’s not done. It’s almost done, which is a very different thing.
When a ticket is truly done, take a few minutes to clean it up. Remove the Developer Notes section (it served its purpose). Add screenshots of the finished work. Link the pull requests next to their related acceptance criteria items. Mark each deliverable with a ✅.
Why bother? Because six months from now, someone will ask “how does this feature work?” or “when did we ship that?” A well-closed ticket becomes living documentation. A sloppy one becomes a dead link that nobody trusts.
Icebox: How much do we have left?#
The icebox is where future ideas live. It’s everything the team might work on eventually, but not right now. Feature requests from stakeholders, technical debt someone noticed, ideas that came up during retro, that “we should really fix this someday” conversation from last month.
The key difference between the icebox and the backlog: the backlog is a commitment, the icebox is a parking lot.
Tickets in the backlog are refined, prioritized, and ready to be picked up. Tickets in the icebox might be half-baked, might be missing acceptance criteria, might be a single sentence. That’s fine. The icebox is not a place for polished work. It’s a place to capture ideas so they don’t get lost.
Keeping the icebox useful#
The icebox gets messy fast. Without occasional grooming, it turns into a graveyard of tickets nobody will ever look at again. A few practices that help:
- Review it during planning. When deciding what goes into the backlog next, scan the icebox. You may find something that’s suddenly relevant.
- Delete aggressively. If a ticket has been in the icebox for months and nobody has mentioned it, it’s probably not important. Delete it. If it matters, it’ll come back up.
- Don’t use it as a guilt pile. The icebox is not a list of things you “should” be doing. It’s a list of options. If having 200 tickets in the icebox stresses the team out, trim it down to the 20 that actually have a chance of getting worked on.
The icebox answers the question “how much is left?” for stakeholders. But be careful with how you frame it. A full icebox doesn’t mean the project is behind. It means the team has more ideas than capacity, which is healthy. The backlog is what tells you how much committed work remains.