During Iteration execution, a team's velocity tends to be most affected by what?

Question

Options

• AProduct Owner changes, changing estimations, and new Features
• BChanging team size, team makeup, and technical context
• CChanging financial planners, a new Scrum Master, and new testers
• DProductivity changes, team location, and innovation measures

• A
  5% (1)
• B
  90% (19)
• D
  5% (1)

Explanation

Velocity reflects what a stable team can deliver - so the factors most likely to disrupt it are changes to the team itself: its size (more or fewer people changes raw capacity), makeup (swapping in new members disrupts established rhythm and trust), and technical context (new tech stack, tooling, or codebase complexity directly affects how fast work gets done). These three variables sit at the core of why velocity exists as a metric in the first place.

Why the distractors are wrong:

• A - Product Owner changes and new Features affect what is built, not necessarily how fast the team builds; estimate changes are a symptom, not a root cause of velocity shifts.
• C - Financial planners have no direct role in iteration execution, and a new Scrum Master or testers, while potentially disruptive, are far less impactful than wholesale team size/composition changes.
• D - "Innovation measures" and "team location" are vague and secondary; productivity changes are an effect of velocity disruption, not a cause.

Memory tip: Think of velocity as a team fingerprint - it's unique to that specific group of people working together in that specific context. Change the team's size, who's on it, or what technical environment they're in, and you've changed the fingerprint entirely.

No community discussion yet for this question.