The board didn't make you overcommit. It just made it impossible to hide.

A team I worked with was certain Kanban was the cure. They'd been underwater for two quarters, so they put up a board, drew some columns, and waited for the calm to show up. Three weeks later the board was a wall of sticky notes, every column jammed, and the same people were working the same late nights. Nothing had changed. Now everyone could just see the mess in one place.

Here's the uncomfortable part. Kanban isn't a productivity system. It's a mirror. It shows you exactly how much you've already said yes to. If your team's real problem is that it can't say no, a board won't rescue you. It'll document the drowning in real time, in nice neat columns.

What the board is actually for

The book version of Kanban is short: make the work visible, limit work in progress, manage the flow. A few columns, a couple of rules, done. Lean folks will tell you it goes deeper than that, and they're right, but most teams start here.

What actually happens is teams adopt the first rule and quietly skip the second. They visualize everything and limit nothing. So the board fills, because of course it does. Visualizing work without limiting it is like swapping to a bigger plate at a buffet. You can see all the food now. You're still going to make yourself sick.

DORA, Google's long-running delivery research, is blunt about the mechanism. When faced with too much work and too few people, it says, inexperienced managers spread people across many tasks hoping to raise output, and the result is that tasks take longer to finish and the team burns out {DORA, Work in Process Limits}. The fix was never a tool. It's a decision to do fewer things at once.

Why more in progress means slower, not faster

There's a piece of math here that doesn't care how you feel about it. Little's Law says the time it takes work to get through your system is roughly the amount of work in progress divided by how fast you finish things. Hold your finishing rate steady and double what's in flight, and the wait doubles too. Everything takes twice as long to come out the other end.

This is the bit that breaks people's intuition. Starting more work feels like progress. Ten things moving looks productive. But moving and finishing are different verbs, and only one of them ships. A team with ten things at half-done has delivered nothing. A team that finishes two, then two more, is shipping while the first team is still almost there on all ten.

So the late nights aren't a sign your people aren't working hard enough. Usually they're working too hard, on too many things, none of which can finish because they keep getting interrupted by the next thing that also can't finish.

The jam starts upstream of the board

Here's where the board gets blamed for something it didn't do. The pile-up in your columns didn't begin on the board. It began in every meeting where someone asked for one more thing and your team said sure, we'll fit it in. The board is downstream of your yeses. It only shows you the bill.

That's why no tool saves a team that can't say no. Jira, Trello, a wall of paper, it makes no difference. The constraint isn't visualization. It's demand. You're taking in more than you can finish, and rearranging columns doesn't change that arithmetic.

And a lot of what gets a yes was never going to matter. In a study presented back in 2002, the Standish Group reported that across the applications they looked at, around 64% of features were rarely or never used once they shipped. Worth the fine print: that figure came from only four internal applications, so treat it as a hint, not a law of nature {Standish Group, via Mountain Goat Software}. But any Scrum Master who has watched a must-have feature ship and then gather dust knows the shape of it is right. Plenty of the work fighting for room on your board doesn't deserve the room.

Let the limit say no for you

So here's the coaching move. A work-in-progress limit isn't a productivity feature. It's a sentence you get to say in a room without being the difficult one. We're at our limit. This can go next, but something has to come out first. The board says no on your behalf. That's its real job.

Setting one is simpler than it sounds, and harder than it looks.

• Count what's actually in progress. Not planned, not in the backlog. In progress, right now. Most teams are quietly shocked by the number.

• Set the limit below that number. If six things are moving, cap it at three. It'll feel wrong. Do it anyway, because the discomfort is the point.

• Make new work meet the limit, not you. When something new arrives, point at the board. The answer isn't no. It's not yet, and not without a trade.

• Make the queue visible to stakeholders. When people can see the line, the conversation shifts from do it all to what's first.

That last one matters more than it looks. DORA's own advice is to set up a regular meeting where stakeholders order all the work, and to tell them plainly that anything nobody prioritizes won't get done {DORA, Work in Process Limits}. You're not refusing anyone. You're making them choose. That's a different job, and a more senior one.

What this sounds like in an interview

This is a positioning thing too. When an interviewer asks how you've used Kanban, the junior answer is mechanical. I set up the columns and we moved cards across. Fine. Forgettable.

The strong answer names the real problem. The team was overcommitted, so I made the work in progress visible and we set WIP limits. The hard part wasn't the board, it was getting the team and the stakeholders to agree on what came out when something new came in. Once we limited what was in flight, our cycle time dropped and we stopped missing dates. That's a person who understands the tool serves a decision, not the other way around. A hiring manager hears the difference in one breath.

So get a board. Use it. Limit the columns. Just be honest about what it can and can't do. It can show you the truth and give you a clean way to say not yet. It can't make the choice for you. Saying no is still a human act, and it's still the most useful one you'll learn in this job. If your columns are always jammed, don't redesign the board. Look at the yeses sitting upstream of it. That's where the fix lives.

Sources

DORA (DevOps Research and Assessment), Google Cloud. "Capabilities: Work in process limits." dora.dev.

Cohn, Mike. "Are 64% of Features Really Rarely or Never Used?" Mountain Goat Software (citing Jim Johnson, Standish Group, XP 2002 keynote).

Little, John D. C. "A Proof for the Queuing Formula: L = lambda W." Operations Research, 1961 (the basis for Little's Law).