The real cost of context switching across milestones

The meeting nobody talks about

Here is a situation that happens in a lot of product teams. It is usually a planning call or a sprint review. Someone asks "how is Milestone B going?" and the honest answer is: slowly. Not because the work is hard, not because the team is lazy, but because the same three people who are supposed to deliver Milestone B are also halfway through Milestone A, triaging bugs in Milestone C, and supporting a customer escalation that technically lives in Milestone D.

The work is real. The effort is real. But the milestones are not moving.

Most teams reach for explanations that are more comfortable. The estimates were off. There was unexpected complexity. We had some unplanned work. All of those things may be true. But underneath them, almost always, is a simpler problem: too many milestones running at the same time, with the same people assigned to all of them.

Gerald Weinberg put numbers on this in Quality Software Management. His table is not uniform: two projects means roughly 20% overhead, three projects means 40% total overhead, and five projects leaves you under 25% effective. Each additional project adds more than the last, because switching cost is not linear. DORA research has consistently found that organizational instability, including shifting priorities, correlates with lower performance and higher burnout. It is the same mechanism, viewed at a team level instead of an individual one.

GoalPath applies penalties derived from Lean research on concurrent work streams. The thresholds are calibrated per person, based on how many milestones each individual is actively working across at once:

• 1 milestone: No penalty. Full velocity.
• 2–3 milestones: 15% penalty. Manageable, but real.
• 4–7 milestones: 30% penalty. Significant throughput loss.
• 8+ milestones: 50% penalty. Half effective capacity gone.

These feed directly into each person's contribution to the forecast. The more milestones a person juggles, the less of their capacity counts toward any single one.

Why teams almost never see this

The problem with context switching is that it is invisible in most tracking tools. Your Jira board shows items moving through columns. Your burndown chart slopes downward. Everyone is busy. Nothing is obviously wrong.

What you do not see is the effective velocity. The number of story points your team could deliver if they were focused, versus what they actually deliver when they are split across five active milestones.

Most teams learn about their multitasking penalty at the end of a quarter, when they look back and realise three milestones they planned to finish are sitting at 60%, 70%, and 80% done. Each one almost there. None of them shipped. The Friday status email goes out, and someone writes "good progress across the board." Good progress. Nothing delivered.

That is what the 15–30% penalty looks like in practice. Not a dramatic crash, just a steady erosion of throughput that never shows up until you zoom out.

What GoalPath sees that your status email cannot

GoalPath tracks which milestones each team member is currently active on. Not historically, right now. It looks at in-progress items, finds which milestones each person is actively working across, and calculates a multitasking penalty for each person based on their concurrent milestone count.

That penalty feeds directly into the forecast.

When you open the Duration Forecast panel on a milestone, you will see a "Velocity Impact" section if GoalPath has detected multitasking. It shows the penalty percentage and labels it clearly: "Team velocity reduced due to parallel work streams." The effective velocity shown in the calculation breakdown is the number the forecast is actually built on, already adjusted downward.

Most forecasting tools (spreadsheets, rough estimates, gut feel) assume the team is fully focused on the milestone being projected. They use the raw velocity, the number from when things were going well. GoalPath uses the effective velocity: what the team can actually produce right now, given the number of tracks they are juggling. The two numbers are often far apart.

The Coordination Impact card

The Velocity Analytics page has a card called "Coordination Impact." It appears only when GoalPath detects a project-wide multitasking penalty, meaning enough team members are spread across enough milestones that it is affecting aggregate throughput.

It shows a single percentage: the share of velocity being lost to coordination overhead. Not a theoretical estimate. A calculation from the current state of the project.

When this number is high, the right question is not "how do we go faster?" It is "what can we stop doing simultaneously?"

The ritual it replaces

Most teams learn about their multitasking problem through a retrospective. Something slipped, someone asks why, a senior engineer explains that they have been pulled in six directions. The team agrees to "be more focused." Two weeks later, the planning meeting adds two more parallel tracks because a stakeholder wanted two things.

The retrospective is the replaced ritual. The value is not in the conversation after the slip. It is in seeing the penalty before the commitment is made.

When you are looking at a milestone forecast in GoalPath and you see the effective velocity is 30% lower than the raw velocity because three of the five people assigned to this milestone are also active on two others, you have the data you need before the planning meeting. Not after the quarter ends.

That is the mechanism: guided workflow produces per-person WIP data across milestones, the velocity service applies empirically derived penalties, and the forecast reflects what will actually be delivered. Not what could be delivered in a world where everyone is fully focused.

When running parallel tracks makes sense

Not all parallel work is waste. There are real situations where multiple milestones should be in flight at the same time:

Different teams, different tracks. If your frontend team is building the UI for Milestone B while your backend team finishes Milestone A's API, that is not multitasking. That is parallel specialization with low switching overhead. GoalPath's team-based velocity calculations handle this correctly, tracking velocity per team rather than blending everyone together.

Dependencies with wait time. If Milestone A is blocked on an external dependency for two weeks, it makes sense to start Milestone B rather than idle. The key is that people are not actively working both at the same time.

Short, unrelated bursts. Incident response, a critical bug, a compliance deadline: sometimes two things genuinely have to happen. These are real, and pretending otherwise just means making promises you cannot keep.

The problem GoalPath is designed to detect is not "two things in flight." It is "six things in flight, with the same core engineers on all of them, and forecasts that do not know it."

A practical check you can do right now

Open your project in GoalPath. Go to Velocity Analytics. If you see a Coordination Impact number above 15%, you have a multitasking problem worth addressing.

Then open the milestone you are most worried about, the one with the nearest deadline or the most stakeholder attention. Expand the "Calculation Details" section in the forecast panel. Look at the raw velocity versus the effective velocity. The gap is the cost of context switching, expressed in points per week.

If the gap is large, you have two options. One is to accept the forecast as-is and negotiate scope or timeline. The other is to reduce active milestones, either by finishing one before starting another, or by moving people off tracks they do not need to be on right now.

GoalPath does not make that decision for you. But it makes the cost visible, in the same place where you are already looking at delivery dates, before you commit to something that the data says you cannot deliver.

That is what most teams are missing. Not the knowledge that context switching is bad. Everyone has heard that. What they are missing is a number, attached to their actual team, for the milestone they are actually planning, visible before the promise is made.

---

Further reading

• Gerald Weinberg's multitasking overhead table: Coding Horror: The Multi-Tasking Myth
• The 2024 DORA report on organizational stability and productivity: dora.dev/research/2024
• SEI on context switching in DevOps environments: SEI Blog: Addressing the Detrimental Effects of Context Switching with DevOps
• Research on task switching and software development: ResearchGate: Impact of task switching and work interruptions on software development processes