The least disruptive descope is the one that loses the least context.
When your team takes on too much and something has to give, the reflex is to count tasks. You list everything in flight, find the pieces you can drop or move, and hand off the ones that look self-contained. The team has fewer items, so the problem looks solved.
Task count is the wrong measure.
Here is a real case from July. One team ran five tracks at once: a plugin platform, a batch of integration migrations, a forms rebuild, an agentic connector, and an enterprise customer integration. All five were in progress. None were finished. The team worked past a sustainable pace, and everyone felt it. Some work had to go.
The obvious move was to hand off the platform. It was the biggest and most demanding track, and a central team could plausibly take it. Cut the largest item and you free the most room. On a task count, that option wins.
It was also the worst option. The reason only shows up when you change the question.
The team built the platform from nothing. They hold more context on it than anyone else in the company. Give it to another team, and that team spends months learning what your team already knows. The work slows down when it moves, because it now sits with people who do not understand it yet. The context does not move with the ticket. It stays with the people you took off the work.
Ask what’s cheapest to lose
So ask a different question. Skip “which track is biggest?” Ask “which track loses the least understanding when it changes hands?”
The answer changes. In this case, the right things to hand off were the enterprise integration and a separate feature the team had been carrying. The team held shallow context on both, and neither was core to its direction. More items changed hands than in the plan to give away the platform. Far less knowledge left the team. The team kept the work where its context was deepest and gave away the work where its context was thinnest.
Moving the fewest items and losing the least context often point to different choices. The descope that looks cleanest on a slide moves one big item in one piece. It often loses the most, because an item gets big when someone spends a long time building the knowledge to run it.
Two checks
Two checks confirmed the choice.
First, the team reached the same answer on its own, before seeing any options. In the retro they named the problems directly: too many repos, slow reviews because half the code was unfamiliar, and keep-the-lights-on work crowding out the work they wanted to build. Each of those is a context problem. Shedding the low-context tracks was the fix they already wanted.
Second, it matched the business strategy. The platform is the strategic bet. The individual plugins are not. Keeping the team on the platform protected its context and followed the direction leadership had already set. When the context case and the strategy case point to the same track, you can stop deliberating.
One caveat. A handoff works only if another team takes the work. You can name what to shed. You cannot, by yourself, promise the receiving teams have room for it. That decision belongs to whoever owns capacity across teams. A handoff with no confirmed receiver is not a plan. If you use this approach, take that question to the person who owns cross-team capacity and get an answer. Without that answer, you have only a list of where you want the work to go.
This is also why a team’s best call often leaves no visible artifact. Protecting deep context looks like nothing happened. A reorg that moves one big item looks decisive and loses the most.
When your team is overloaded, do not start with what is easiest to remove. Find where your team’s context is deepest, keep the team there, and give away the work that costs the least understanding to lose. Your task count may go up. That is fine.