Arguing from the Scrum Guide will lose
The weakest version of this answer cites self-management, points out that the Developers decide who does what and when, and stops. It is correct and it will change nothing, because you have told a manager who believes their arrangement works that a document disagrees with them. The team has already said it is fine, so you are now the person defending process against two parties who are content. That is the position from which Scrum Masters become an overhead the organisation tolerates.
The useful move is to argue from what it costs, and there is a specific mechanical cost here that most people never articulate.
What assigning everything on day one does to flow
Assignment at planning almost always produces the same pattern: every developer leaves the meeting with work, so everything starts at once. Six developers each holding two items means twelve items in progress from day one of the Sprint, and that is not a scheduling detail, it is the dominant factor in how long anything takes.
Put numbers on it from the team's own history. Suppose the team completes about six items per two-week Sprint, which is three items a week. With twelve items in progress on average, the average time an item spends in progress is twelve divided by three, which is four weeks — longer than the Sprint, which is precisely why items carry over. If the same team held four items in progress at a time, the average would be four divided by three, about one and a third weeks. Same people, same throughput, cycle time cut to a third, purely from not starting everything at once. That relationship between work in progress, throughput and cycle time holds on averages regardless of process, so it is not a matter of preference.
Three consequences follow, and they are the things the team is currently experiencing without attributing them to planning. Feedback arrives late, because nothing finishes early in the Sprint. Nobody helps anybody, because each person has their own two items and helping means falling behind on your own. And the Sprint Goal becomes decorative, since twelve simultaneous single-owner items are twelve individual plans rather than one team plan.
That is the argument to lead with, and notice that it never mentions self-management. It mentions carryover, which the team complains about, and slow review turnaround, which the manager complains about.
Test "it works fine" rather than accepting or dismissing it
The team's claim is data and you should treat it as such, in both directions. Look at what the board says: how much work carried over in each of the last six Sprints, how long items sat waiting for review, how many items were in progress at the midpoint of each Sprint, and whether the same person picks up the same category of work every time. If the numbers are healthy, the team is right and you should say so. If they are not, you have converted an argument about authority into an observation about the last three months.
There is a second, quieter cost the numbers will show you: specialisation hardening into a single point of failure. Assignment optimises each item for whoever is fastest at it, which is locally rational and, repeated for a year, produces four people who each own one area and cannot cover for one another. Count how many people have touched each part of the system in six months. A team where every component has exactly one plausible owner is a team that cannot absorb a holiday, and that fact is much more persuasive to a manager than a principle is.
Also ask individually rather than in the room. "It works fine" is what a team says in front of its line manager, and the more interesting answers arrive in one-to-ones — the engineer who has not worked on anything new in a year, the one who wanted to pair on the payments code and was never allocated to it.
Serve the manager's actual need
The manager is doing this for a reason and it is rarely a desire for control. Find out which reason, because each has an alternative that does not require assignment.
| What the manager needs | What you can offer instead |
|---|
| Confidence that the unglamorous work is not left | A working agreement that the top unclaimed item is pulled next, and it is visible when it is not |
| A view of who is doing what, for reporting or reviews | A board that shows the work and its owner as it is pulled, updated daily |
| Balanced development across the team | A named growth goal per person that they steer through the assignments the team makes |
| Reassurance that nobody is idle or overloaded | Work-in-progress limits and cycle time, which show load far better than a list of names |
| Speed, because pairing on decisions feels slow | Planning that decides the goal and the first two items, then leaves the rest to be pulled |
Framing matters: the ask is not "stop doing this", it is "here is a way to get what you want that also cuts our carryover". A manager who is offered a better route to their own objective is an ally, and one who is told they are violating a framework is not.
Change one thing, and keep the change
Do not propose a redesign of planning. Propose one experiment, for two Sprints, with a measure attached. The version that works most often is to keep the manager in planning and change what leaves the room: the team agrees the Sprint Goal and pulls only the first few items, with a limit on how much can be in progress, and everything else stays unassigned until somebody is free to pull it. Nothing about authority has been contested; the change is the timing of the assignment rather than who makes it.
Then measure the two things you predicted — carryover and the number of items in progress at the Sprint midpoint — and take the result to the same room. If it improved, you now have evidence rather than an opinion, and the second change is far easier to get. If it did not, you have learned something and you have spent no political capital claiming otherwise.
Expect drift, because habit reasserts itself. The most common relapse is that the limit stays nominally in place while items are pulled anyway to look busy on day one. That is why the measure matters more than the agreement: a working agreement nobody checks is a decoration.
When the team is right
Sometimes the evidence comes back and the arrangement genuinely is not hurting anything: carryover is low, cycle time is stable, several people can work on each area, and nobody is unhappy in private. Then the honest conclusion is that this team has a working practice that does not match the framework's expectation, and that pushing further would be a change made for the sake of orthodoxy.
Being willing to say that is a stronger interview answer than insisting on self-management everywhere, provided you can also say what you would still watch: whether anybody is growing, whether the manager's absence for a fortnight causes a problem, and whether the team could change its own working practice if it wanted to. That last one is the real test of self-management, and it is not about who assigns tickets. A team that could change how it works if it chose to is self-managing whatever planning looks like; a team that could not is not, and the assignment is a symptom rather than the illness.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).