How will team changes impact velocity of a Scrum project?

Question

Question

If there are 8 members in a team assigned to complete the project. 20% of the team left during the particular sprint. Does the velocity change? If so, what would the velocity changes be?

Context

I am preparing for Scrum master certification right now. So my role would be Scrum Master. I'm concentrating more on velocity of the team related questions. Assuming that in a project, we have 8 cross-functional members in the team. Project should be completed within 4 Sprints. 2 members of the team left because they are ill. The project should continue.

I want to know if the velocity of the team changes for the current Sprint and the following Sprint. If so, what velocity changes should we expect?

Answer 1

Velocity and Capacity

20% of the team left during the particular sprint. Does the velocity change?

It is likely that your velocity will change because the team's capacity has changed, but a lot depends on the work that the team has planned for the Sprint and the cross-functional composition of the team. As a rough planning value, you should probably assume that you will lose 20% of your capacity for the current Sprint, but the Development Team should determine the appropriate fudge factor to apply during Sprint Planning. It may be more or less than 20%, depending on the work selected for the Sprint.

Over time, your velocity will either smooth over a one-off blip in team capacity, or trend towards a new average if this is the new norm for the team. Either way, this sort of trailing metric is essentially self-correcting. Changes in the team or the process will generally result in changes to velocity, and that's as it should be. As long as you aren't using it incorrectly as a productivity metric, you should allow the data to correctly reflect these changes rather than forcibly recalibrating the metric.

Velocity and the Sprint Goal

The correct use of velocity is to determine whether all the work needed to meet the current Sprint Goal can fit within a single Sprint. If Sprint Planning results in a Sprint Backlog that exceeds the Development Team's expected capacity for the current Sprint, the work selected (and possibly the Sprint Goal) will need to be renegotiated.

In other words, it is unlikely that a team of 6 will have the same capacity as a team of 8, so less work should probably be selected for the current Sprint. Velocity (with appropriate fudge factors) can provide a sanity check for the team and help avoid oversubscription, but in the end the Development Team is committing to achieving a Sprint Goal rather than delivering a set number of story points.

Focus on the Sprint Goal, not the velocity forecast. If you don't have a Sprint Goal, then fix that process problem ASAP. Focus on delivering the Sprint Goal, and let the velocity metric speak for itself.

Answer 2

You may be conflating two term here - velocity and capacity. Velocity is only measurable after the sprint and will most certainly be less for this sprint because you are short 2 people (by 20% left I'm assuming you mean that two people are on vacation or are in some other way not available).

Capacity, on the other hand is more of a prediction ahead of time. If my past sprint velocities have been 30, 32, 29, and 33, I would predict that the team will probably finish around 30 story points if the next sprint was normal. However, with two people missing, I'd probably plan my sprint goal around more like 22.

And this brings up one more slightly tangential point. Using past velocity to forecast future output has risks. In particular, story points (or even backlog item count) are very rough numbers in the best circumstances. Trying to "fill the team's capacity" in this way will almost always result in missed targets, cut corners, and sub-optimal performance. Rather, it helps the PO form their initial sprint target going into planning (what they hope to accomplish and what backlog items would lead to that) and it acts as a check against overcommitment (if at the end of planning that same team had 40 points in the backlog, our past velocity says we are unlikely to meet that goal).