1

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?

  • 1
    Welcome Priyanka! Can you please describe your problem with more detail? What is your role in this project? – kriscorbus Apr 29 at 15:17
  • Velocity <> Capacity. Velocity is a trailing metric for forecasting capacity, but you shouldn't be using capacity to plan velocity. – Todd A. Jacobs Apr 29 at 16:21
  • Why not? If half of the team is off for vacation, the velocity will change. Biggest scrum mistake is to take the velocity as it is, never think about what is behind. The relationship between velocity and capacity is not 1:1 – Zsolt May 3 at 13:05
3

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.

1

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.