The Hum That Doesn’t Stop
You know the feeling. It’s 9pm. You’re technically done with work. But there’s a background hum — a low-grade, persistent murmur of things that aren’t finished. The PR you opened but didn’t merge. The story you started but left in review. The bug you triaged but haven’t looked at again. It’s not loud. It’s not urgent. It just… hums.
Now multiply that by fifteen people and twenty-three items in the “In Progress” column. That’s not a Kanban board. That’s a cognitive stress test.
Here’s the thing: that hum is not a character flaw, a productivity problem, or a lack of discipline. It is your brain doing exactly what it is designed to do. It is following a principle first identified in a Berlin café in 1926 by a young Soviet psychology student named Bluma Zeigarnik — a principle that went on to explain, more precisely than any agile framework has managed, why limiting work in progress is not just a flow optimization. It is an act of cognitive mercy.
Bluma Zeigarnik was studying under the gestalt psychologist Kurt Lewin in Berlin when she — or possibly Lewin himself, accounts differ — made an observation about a nearby waiter. The waiter could hold an extraordinary number of complex, multi-item orders in his head simultaneously. But once the orders were delivered and paid for, they were simply gone. He couldn’t recall them. The completed orders vanished. The incomplete ones stayed vivid.
Zeigarnik went back to her lab and ran a study. Participants were given a series of tasks — puzzles, arithmetic problems, simple construction tasks. Half the participants were interrupted mid-task. Half completed their tasks normally. Afterwards, she asked everyone to recall as many tasks as they could.
The interrupted participants recalled their unfinished tasks approximately ninety percent better than the completed ones. The completed tasks? Largely forgotten. The paper, published in 1927, documented what is now called the Zeigarnik Effect: unfinished tasks occupy a privileged, persistent position in working memory in a way that completed tasks do not.
For agile coaches, this finding is not an academic curiosity. It is the mechanism underneath every WIP problem you have ever tried to solve.

The Mechanism: How Your Brain Keeps Score
The Zeigarnik Effect isn’t mystical. It has a concrete cognitive mechanism, and understanding that mechanism is what turns this from a fun psychology fact into a coaching tool.
Open Loops and Working Memory
When you begin a task, your brain allocates cognitive resources to it. It opens what psychologists call a “memory trace” — a kind of active file that stays open, consuming background processing capacity, until the task reaches completion. Zeigarnik’s insight was that this file doesn’t passively wait. It actively pings your conscious attention. It resurfaces unprompted. It keeps itself in play.
This is the “open loop.” And every unfinished item in your system creates one.
Working memory — the part of your cognitive system that holds and manipulates information in the foreground of awareness — is sharply limited. The classic estimate, from George Miller’s 1956 paper, is that we can hold roughly seven items (plus or minus two) in working memory at once. More recent research puts the practical limit lower. The point is not the exact number. The point is that working memory is a finite resource, and open loops are consuming it whether or not you’re actively thinking about them.
This is why a team with twenty-three items in progress doesn’t just have a flow problem. They have a team of people walking around with twenty-three background processes running on limited hardware. Everything feels slower. Focus becomes harder to achieve and harder to sustain. Interruptions feel more costly because context-switching between open loops is more taxing than switching between clear, bounded tasks.
The Ovsiankina Effect: The Urge That Won’t Quit
Zeigarnik’s colleague Maria Ovsiankina identified a companion phenomenon in 1928 that makes this even more interesting for coaches. The Ovsiankina Effect describes the tendency — essentially universal across her study participants — to spontaneously resume an interrupted task when given the opportunity, even without any instruction to do so.
It’s not just that we remember unfinished work better. We are actively drawn back toward it. The open loop doesn’t just occupy memory — it generates behavioral pressure toward closure.
This explains a pattern I see constantly in teams with high WIP: people keep picking up half-done work not because it’s the highest priority, but because the open loop is pulling them. The developer who doesn’t start the new sprint story until they’ve checked on that lingering code review. The product owner who can’t stay focused on discovery because they’re mentally anchored to the feature that’s been “in progress” for three weeks. The Scrum Master who keeps circling back to the impediment they raised but never resolved.
They’re not disorganized. They’re responding to Ovsiankina pressure. The open loops are running the agenda.
The Closure Effect: Why Done Is Actually Done
Here’s the flip side — and this one is underused in coaching.
Completed tasks are forgotten. Not immediately, not entirely, but the cognitive release upon task completion is real and documented. When an open loop closes, the brain releases those allocated resources. The memory trace deactivates. The background hum stops.
This is called the Closure Effect, and it has two implications for agile teams that I think about all the time.
First: the value of finishing a thing is not just the output. It is the cognitive release. When a team pulls a story to done — genuinely done, deployed, accepted — they are not just delivering value to a user. They are freeing up working memory across the entire team. That is a real, measurable benefit that your velocity charts will never capture.
Second: this is exactly why completion ceremonies matter. When your team ships something and nobody marks it done, nobody demonstrates it, nobody says “that’s closed” — the open loop doesn’t fully close even though the work is finished. The brain needs a signal. Done needs to feel like done. Sprint reviews, deployment announcements, explicit acceptance — these are not bureaucratic rituals. They are cognitive closure events. They are the mechanism by which your team’s brains are allowed to let go.
This is also why “stop starting, start finishing” is not just a Kanban slogan. It is applied cognitive science.
WIP Limits and Collective Cognitive Load
Individual working memory is limited. Team working memory — the distributed cognitive load carried across a group — is also limited, and the Zeigarnik Effect operates at the team level just as clearly as it does at the individual level.
When a team has fifteen items in progress, the cognitive cost is not carried by one person. It is distributed across everyone who has context on any of those items. Every standup is slightly longer because there are more open loops to report on. Every conversation is slightly more taxing because more half-done things need to be held in mind. Every handoff is slightly more lossy because the person handing off is managing their own constellation of open loops while trying to transfer context.
A WIP limit is not a constraint on output. It is a constraint on the number of open loops the team is permitted to carry simultaneously. It is the team deciding, deliberately, to stop letting the Ovsiankina Effect run their backlog.
What This Changes About Your Coaching
Making the Case for WIP Limits
If you’ve ever tried to introduce WIP limits to a team that views them as artificial restrictions, you know the conversation. “But we’re not blocking anyone.” “We’re working in parallel to go faster.” “This just feels like bureaucracy.”
The Zeigarnik Effect gives you a different argument — one that doesn’t rely on flow metrics or Little’s Law or throughput calculations. It grounds the conversation in what the team is actually experiencing.
Ask them to describe how it feels to work right now. Not what the metrics say. How it feels. Nine times out of ten, the words that come up are “scattered,” “unfocused,” “exhausted,” “like I’m spinning plates.” Those aren’t personality complaints. Those are people accurately describing the cognitive experience of carrying too many open loops.
Then you can name it. “What you’re describing is the Zeigarnik Effect. Every item in your In Progress column is an open loop in your collective working memory. You’re not scattered because you’re bad at your jobs. You’re scattered because your brain is doing exactly what brains do with unfinished work.”
The WIP limit, reframed, is not a productivity constraint. It is a deliberate act of cognitive hygiene. You are choosing to carry fewer open loops. You are choosing, as a team, to protect your own focus.
That lands differently than “the metrics say we should limit WIP.” Especially with senior engineers and experienced product people who have real-world instincts that sometimes conflict with the theory. Give them the mechanism. They’ll trust the constraint more when they understand why it works.
Sprint Planning and the Hidden Cost of Overcommitment
Sprint planning is where many teams accidentally manufacture suffering, and the Zeigarnik Effect explains the mechanism precisely.
When a team pulls more into a sprint than they can reasonably complete — which is most teams, most of the time — they are not just creating a velocity problem. They are front-loading the sprint with open loops that will never close within the timebox. The stories that don’t make it to done will carry over. And carry-over stories are particularly costly under the Zeigarnik Effect, because the open loop persists across the sprint boundary. The team enters the next sprint already carrying cognitive debt from the last one.
The hidden cost of overcommitment is not just the slipped story. It is the accumulated open-loop load that compounds across sprints.
This is worth naming explicitly in sprint planning conversations. When a team is debating whether to pull in one more story — the eternal “we can probably get to it” negotiation — the Zeigarnik framing adds a concrete consideration: if this story isn’t finished by the end of the sprint, what does it cost us to carry that open loop for another two weeks? What’s the cognitive weight of that ongoing incomplete?
Sometimes the answer is: worth it, this story has high enough value and high enough probability of completion. But at least the team is making the trade-off consciously rather than accidentally manufacturing another source of background hum.
Helping Individuals With Focus and Burnout
The Zeigarnik Effect is not just a team phenomenon. It operates powerfully at the individual level, and coaches who understand it are better equipped to help developers, product managers, and other practitioners who are struggling with focus, overwhelm, or early-stage burnout.
When someone comes to you saying “I can’t seem to concentrate,” the standard coaching move is to look for environmental distractions, workload volume, or personal circumstances. Those are valid angles. But another angle worth exploring is their personal WIP. How many things do they have technically started? How many open loops are they carrying that have no near-term path to closure?
A task list with thirty items on it is not just a workload problem. It is thirty open loops generating thirty persistent memory traces, quietly consuming cognitive bandwidth around the clock.
One of the most powerful things you can do with an overwhelmed individual is walk them through a simple exercise: for every open loop they’re carrying, either close it (do it, delegate it, or explicitly drop it) or park it in a system they trust to remind them at the right time. David Allen’s Getting Things Done captures something similar with the idea of a “trusted system” — the reason the GTD brain dump feels relieving is precisely because it offloads open loops from working memory into an external system, allowing the brain to release the memory trace.
When coaching leaders or practitioners through burnout, the Zeigarnik framing can also help them reconnect with the value of finishing things. People in burnout often describe a sense of futility — the feeling that nothing ever gets done. This is sometimes literally true (too much WIP, nothing reaches closure), but it is also sometimes a perceptual artifact of the Closure Effect. If completions aren’t being marked, celebrated, or noticed, the brain doesn’t register them as closures. The pile of open loops grows. The sense of accomplishment shrinks. Even on teams that are shipping regularly, if done doesn’t feel like done, the cognitive experience is one of permanent incompletion.
What It Looks Like in the Room
Priya had been coaching the platform team for six weeks when she finally asked to see the board.
Not the sprint board. The Kanban board for the whole team’s work — the one they kept in the corner of the space and updated inconsistently and referred to when the sprint board didn’t tell the full story. She’d been hearing references to it for weeks without actually sitting down in front of it.
There were twenty-seven items in the In Progress column.
Some were old — one card had been sitting there for eleven weeks, which was longer than Priya had been coaching the team. Several had two or three people’s names on them. A handful had no names at all. Three of them were labeled “blocked,” which raised the question of why they were in In Progress rather than Blocked, but that was a separate conversation.
She called an impromptu team huddle around the board. Eight people, plus the product manager, Karan, who had wandered over from his standing desk.
“Walk me through what In Progress actually means on this board,” Priya said.
What followed was illuminating. For some cards, In Progress meant actively being worked. For others, it meant someone had started it and set it down to handle something more urgent. For others, it meant it was waiting for review but the author was already on something else. For one card — the eleven-week-old one — it meant nobody was sure whether it was still relevant, but nobody wanted to close it without checking with the architect, who was on a project in another timezone.
“How does it feel to work here right now?” Priya asked the room.
The responses came quickly, which told her something. When you have to think hard about how it feels, usually it feels fine. When the words come fast, usually they’ve been bottled up.
“Like I’m always half-focused.”
“Scattered. Like I’m always picking up threads.”
“I feel guilty going home because nothing’s done.”
“Honestly? Like the board is judging me.”
That last one landed. Several people laughed, but it was recognition laughter, not dismissal.
Priya drew a quick diagram on the whiteboard. A brain. A pile of tasks next to it, with arrows going from each task into the brain. “This is what Bluma Zeigarnik found in 1927. Your brain doesn’t file away unfinished work. It keeps an active, running process for every incomplete task — consuming cognitive resources whether you’re thinking about it or not. Every one of those twenty-seven cards is a process running on your team’s collective hardware. No wonder the machine feels slow.”
Karan, the product manager, folded his arms. “So you’re saying the board is making us dumb.”
“I’m saying the board is making you tired. There’s a difference. You’re not less capable. You’re carrying more cognitive weight than any team is designed to carry without cost.”
She proposed an experiment rather than a policy, because policies breed resentment and experiments breed curiosity. For the next two weeks, nothing new goes into In Progress until something comes out. No exceptions without a team discussion. They’d audit the board together, right now, and close or park anything that wasn’t actively moving.
Forty minutes later, seventeen items had been closed (some completed and never marked done, some explicitly dropped with the team’s agreement), two were moved to Blocked for honest accounting, and the In Progress column held eight items.
Eight. For a team of eight people. One per person, roughly.
The shift in the room was visible. Not dramatic — nobody high-fived. But the ambient tension that Priya had noticed since week one — that low-grade hum of overwhelm and scattered attention — was quieter.
Three sprints later, In Progress averaged nine items. Throughput was up. Not because the team was working harder. Because they were finishing things instead of starting things, which meant open loops were closing, which meant working memory was clearing, which meant each person actually had more cognitive capacity available for the work in front of them.
Karan mentioned it in a retro, almost as an aside: “I haven’t felt guilty going home in three weeks. I think we’re actually finishing stuff now.”
That’s the Zeigarnik Effect, working in reverse. When done feels like done — when the loop actually closes — the hum stops. And in the quiet, people can think.
Go Deeper
-
Zeigarnik, B. (1927). “Über das Behalten von erledigten und unerledigten Handlungen.” Psychologische Forschung, 9, 1–85. The original paper, published in German. The title translates roughly as “On the retention of completed and uncompleted actions.” Most coaches won’t read this, but it’s worth knowing it exists and knowing what it actually showed — which is more nuanced than the pop-science summary often suggests.
-
Anderson, J.R. (1983). The Architecture of Cognition. Cambridge, MA: Harvard University Press. The cognitive science underpinning for working memory and how the brain allocates processing resources to active tasks. Technical but foundational if you want to understand why open loops are costly, not just that they are.
-
Kahneman, D. (2011). Thinking, Fast and Slow. New York: Farrar, Straus and Giroux. Kahneman’s treatment of cognitive load, System 2 depletion, and the limits of working memory complements Zeigarnik well. If you’re using both frameworks in coaching, this is where they connect.
-
Anderson, D.J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Sequim, WA: Blue Hole Press. The foundational Kanban text. Anderson’s treatment of WIP limits and flow efficiency is the operational translation of everything the Zeigarnik Effect predicts. Read this for the practice; read Zeigarnik for the mechanism.
-
Allen, D. (2001). Getting Things Done: The Art of Stress-Free Productivity. New York: Viking. Allen’s “trusted system” concept and brain dump exercise work precisely because they offload open loops from working memory to an external system. GTD is Zeigarnik applied to personal productivity, even though Allen never names it that way.