Hidden work in progress: why busy teams still deliver slowly

A developer picks up a ticket on Monday. In the standup she says she's on it. By Thursday she's still on it, and to anyone reading the board, nothing looks wrong: one item, in progress, one owner.

What the board doesn't show is that she has started the work five times. Once at the beginning. Again after a review comment landed on an unrelated pull request and she went to answer it. Again after a customer question arrived through a shared Slack channel and someone tagged her because she'd touched that code six months ago. Again after a dependency she was waiting on finally shipped, and she had to reload what she'd been doing before the wait. And once more after a meeting that turned out not to need her.

Each restart, she had to rebuild what she was holding in her head: which branch, which failing test, what she'd already ruled out, what she was about to try next. None of those restarts show up as work. All of them cost time.

The usual name for this is distraction, and the usual fix is to tell people to focus. That framing is too small. What looks like a lapse in attention is really a delivery problem, and it belongs to whoever manages flow.

The board undercounts work in progress

Work-in-progress limits are supposed to protect a team from carrying too many open items at once. Most WIP discussions stop at the count of tickets. But a person carrying one active ticket can be holding five unfinished problem states: the review she half-answered, the customer question she's still turning over, the thing she was doing before the dependency wait, the meeting follow-up, and the actual ticket. The board says WIP is one. Her head says WIP is five.

Call this hidden WIP: work that is genuinely in progress inside someone's working memory but invisible on any board. You can't limit what you can't see, and a fragmentation problem measured only in Jira tickets will always look smaller than it is.

Developers already know this, and it happens anyway

Meyer, Fritz, Murphy and Zimmermann surveyed 379 professional developers and observed 11 of them at work across three companies (Meyer et al., 2014, FSE). When developers described what a productive day felt like, they pointed to days with meaningful tasks finished and few interruptions or context switches. The intuition is already there. People know fragmentation costs them.

The observed work told a different story. In the small observation sample, developers switched tasks about 13 times an hour and switched activities, a narrower unit, about 47 times an hour on average. So the same people who name context switching as the enemy of a good day are switching constantly through an ordinary one. That gap is the point. Fragmentation is not a matter of individual discipline that some people lack and others have. It's a standing feature of the work, and feeling productive is no protection against it.

The observation sample here is small, eleven people, so treat the specific switch rates as illustrative rather than a benchmark. The survey behind the perceptions is large. The direction is what matters.

Not all of it is noise

It's tempting to conclude that the answer is to shut the interruptions off. That conclusion is wrong, and the evidence says so plainly.

Wiesche studied interruptions across four agile software teams in an exploratory grounded-theory case analysis (Wiesche, 2021, Project Management Journal). The interruptions sorted into three kinds: programming-related work impediments, interaction-related interruptions, and interruptions from the external environment. Some of these carry information the team actually needs: a requirement that changed, a missing piece of context, feedback from a customer that redirects the work before it goes further in the wrong direction. Cut those off and you don't get flow. You get teams building the wrong thing efficiently.

What the teams in that study did was manage the demand rather than suppress it. They retrieved information so a question didn't have to become an interruption. They reduced dependencies so fewer waits happened in the first place. They channeled requests, used ticketing, moved some things into formal meetings, protected quiet time, and used the Scrum Master as a buffer. That's the shift: interruption demand is something you route, batch, and buffer, the way you'd handle any other demand on a system. It isn't something you eliminate.

So the goal isn't a quiet office. It's to keep needed feedback flowing while avoidable restarts stop happening.

Authority, channel, timing, and task all change the cost

The cost of an interruption isn't fixed. It depends on what kind it is and when it lands.

Ma, Huang and Leach ran a controlled lab study with 20 computer science students doing code writing, comprehension, and review, interrupted both on-screen and in person, with physiological and self-report measures (Ma et al., 2024, ICSE). High-dominance on-screen interruptions, the kind that demand attention rather than wait for it, increased time spent on code-comprehension problems by roughly 164 seconds compared with no interruption. Combined in-person and on-screen interruptions affected code-review timing. The effects differed by task type and by interruption type, and the subjective stress measures didn't always move together with the physiological ones.

This is a student lab sample, not an industrial field study, so read it as mechanism rather than magnitude. But the mechanism is useful: the same interruption is not equally expensive everywhere. It's worse during comprehension. It's worse when it demands rather than waits. Timing and channel are levers you can actually pull.

Why restarting is the expensive part

The visible interruption is the ping. The expensive part is what happens after it, when the person tries to get back to where they were.

Altmann and Trafton studied task interruption and resumption (Altmann & Trafton, 2004). In their task setting, the resumption lag, the pause before the first action back on the interrupted task, was roughly double the normal interval between actions. But when a cue was available before the interruption, resumption lag dropped. The mental state you're trying to reload can be partly reconstructed from something you left behind on purpose.

Borst, Taatgen and van Rijn built a computational model backed by two experiments and found that how disruptive an interruption is depends on its duration, the complexity of the interrupting task, and the moment it arrives (Borst et al., 2015, CHI). Interruptions that hit at a low point in the work, between sub-tasks rather than mid-thought, cost less.

Both of these are cognitive studies, not software field studies; neither is specific to development work. What they give you is two design ideas that transfer cleanly. First, the moment matters, so where you can influence it, it's worth interrupting at a natural break rather than mid-problem. Second, a cue left before switching makes coming back cheaper. Resumption cost is not a fixed tax. It's partly under your control.

Where the evidence is thin, and where it isn't

Before the practical part, one honest boundary.

Sanchez, Robbes and Gonzalez analyzed several thousand Mylyn interaction traces from dozens of developers and found work fragmentation correlated with lower observed productivity, with longer switches strengthening the effect (Sanchez et al., 2015, SANER). That's the closest thing here to fragmentation measured in real development work, though only the abstract was available for this piece, so treat the specifics with that limit in mind. And a systematic review of 218 papers on developer experience places fewer interruptions, relevant resources and expertise, and less heterogeneous task context among the factors tied to productivity (Razzaq et al., 2025, ACM Computing Surveys): enough to say interruptions belong in the productivity conversation, not enough to settle it.

What none of this gives you is direct causal evidence that cutting interruptions improves cycle time. That link is thin. What the evidence supports is narrower and still worth acting on: fragmentation is real, it correlates with lower productivity, its cost varies with type and timing, and resumption cost can be lowered by design. Manage it for those reasons, and measure whether your own delivery numbers move. Don't promise the number in advance.

A fragmentation audit

This is work for a Delivery Manager or Agile Coach, not a poster telling people to focus. Treat interruption demand as demand on the system and manage it the way you'd manage any other.

1. Separate needed feedback from avoidable interruption. Spend a week naming interruptions as they happen and sorting each into two piles: information the work needed, or a restart that a better path would have prevented. Wiesche's three categories (work impediments, interaction, environment) are a usable frame. You can't fix the second pile until you stop treating it as the same thing as the first.

2. Route stakeholder demand through a visible intake path. Customer and stakeholder questions that arrive by direct message to whoever last touched the code are the most expensive form of interruption, because they hit an individual mid-task with implied urgency. Give that demand one visible place to land. Now it's queue demand, which you can see, size, and assign, instead of a tap on the shoulder at the worst moment.

3. Batch low-urgency questions into known windows. Most questions are not urgent; they only feel urgent because there's no agreed time they'll be answered. Set known windows for the non-urgent ones. Batching turns many small mid-task interruptions into one handled at a natural break, the lower-cost moment the disruption research points to.

4. Leave a resumption cue before switching. When someone has to put work down, thirty seconds spent writing down where they are pays back the moment they return. Something like: the failing test, the next command to run, the decision that's open, who owns the blocking piece, and the last thing they were thinking. This is the cue effect from the resumption studies, applied by hand. Make it a team habit, not a personal trick.

5. Protect problem-state work first. Not all work is equally fragile. Comprehension, review, and design hold the most in working memory and cost the most to reload. If you can only defend some of the day, defend those. Quiet time and Scrum Master buffering, both used by the teams Wiesche studied, are more valuable spent on comprehension than on mechanical work that survives interruption cheaply.

The goal is fewer restarts

If your teams look busy all day and still deliver slowly, the fragmentation is probably hidden in the gap between what the board shows and what people are actually carrying. One active ticket, five problem states.

The answer isn't to make everyone unreachable. Some interruptions carry the feedback that keeps the work honest, and cutting those off costs more than it saves. Manage interruption demand as demand: route it, batch it, buffer it, and make coming back cheap when a switch does happen.

The developer restarting her ticket for the fifth time isn't distracted. The work handed her five restarts, and nobody was managing that. That's fixable, and it's your job, not hers.

Sources

• Altmann, E. M., & Trafton, J. G. (2004). Task interruption: Resumption lag and the role of cues. Proceedings of the Annual Meeting of the Cognitive Science Society, 26. escholarship.org/uc/item/18b4r661
• Borst, J. P., Taatgen, N. A., & van Rijn, H. (2015). What makes interruptions disruptive? A process-model account of the effects of the problem state bottleneck on task interruption and resumption. In Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems (CHI '15) (pp. 2971–2980). ACM Press. doi.org/10.1145/2702123.2702156
• Ma, Y., Huang, Y., & Leach, K. (2024). Breaking the flow: A study of interruptions during software engineering activities. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (ICSE '24). ACM. doi.org/10.1145/3597503.3639079
• Meyer, A. N., Fritz, T., Murphy, G. C., & Zimmermann, T. (2014). Software developers' perceptions of productivity. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2014) (pp. 19–29). ACM. doi.org/10.1145/2635868.2635892
• Razzaq, A., Buckley, J., Lai, Q., Yu, T., & Botterweck, G. (2025). A systematic literature review on the influence of enhanced developer experience on developers' productivity: Factors, practices, and recommendations. ACM Computing Surveys, 57(1), Article 13. doi.org/10.1145/3687299
• Sanchez, H., Robbes, R., & Gonzalez, V. M. (2015). An empirical study of work fragmentation in software evolution tasks. In 2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER) (pp. 251–260). IEEE. doi.org/10.1109/SANER.2015.7081835
• Wiesche, M. (2021). Interruptions in agile software development teams. Project Management Journal, 52(2), 210–222. doi.org/10.1177/8756972821991365