There’s a fundamental misunderstanding about what the agile system should be optimizing, and it starts with a structural problem common in technical teams: the sprint manager and the line manager are often the same person. When those roles blur, sprint managers default to the lever they understand best, pushing individuals to produce more. Even in a massively underperforming team, focusing solely on total work executed leads your team to burn out.
At the heart of this misunderstanding lies the concept of velocity. It’s the golden metric collected over time to measure sprint progress. As every good physicist knows, velocity is not just speed, it’s a vector. It describes both how fast something moves and where it’s going.
The velocity of your team has two components:
Any management framework is designed to improve the collective velocity of the team. But here’s where people get lost: they focus exclusively on improving the speed of teams rather than addressing the full velocity equation.
The most common failure mode of sprint management is hyperfocusing on speed. Managers call out tickets that scope creep, highlight individuals who are underdelivering, and demand more from their employees, all in a bid to push total velocity up. They want their team to be more efficient, to increase perceived productivity.
This introduces micromanagement and doesn’t treat team members as autonomous adults. But here’s the thing: direction is the variable you actually control.
Your job as a sprint manager is stakeholder management. It’s the distillation of business priorities into the highest-leverage work for the team to pursue. It’s ensuring everyone knows what they should be working on and why it matters. When your team is building the wrong things quickly, you haven’t improved velocity, you’re wasting time.
The execution speed of an individual is a personal attribute tied to their experience level and proficiency. How much a developer produces, their skill development, their career growth: these belong in performance reviews and personal development conversations with their line manager, not in sprint ceremonies.
In many technical teams, the sprint manager and line manager are the same person. This is where the confusion takes root. When you wear both hats, the sprint becomes a convenient venue to address individual performance. Story points start looking like productivity scores, standups become status reports, and the sprint framework quietly shifts from a directional tool into a performance management one. Recognizing this conflation is the first step to fixing it: keep these responsibilities separate, even when they live in the same person.
Sprint frameworks don’t exist to count developer points or track individual output. Over time, any competent manager knows who’s performing well through regular 1-on-1s and code reviews.
Truly improving an individual’s speed limit is a development process that is slow and lies outside the sprint process. Your responsibility as a project manager is not to push this limit but to get out of the way.
So the sprint manager’s job becomes defensive: avoid reducing individual speed. Don’t drag people into unnecessary meetings. Keep quality checks minimal and purposeful so closing tickets isn’t a chore. Introduce processes carefully. Nurture collaboration to prevent blockers.
If you accept that your job is managing direction, not speed, it changes everything:
The sprint framework exists to help teams move fast in the right direction. When you understand that your job is to clarify direction and shield your team from distractions, you can stop micromanaging and start enabling autonomy.
Your team already knows how to work. Your job is to make sure they’re working on what matters.
]]>