Management is concerned and asks you to help them improve, what would be your response?

Your organization has 5 Scrum Teams with 10 members each. Three teams are doing very well developing an average velocity of 45-50 user story points per Sprint. The other two teams are achieving just 15 and 25 points on average per Sprint respectively.

Management is concerned and asks you to help them improve, what would be your response?
A . Assign Developers from high-performing teams to low-performing teams to compensate and stabilize the average velocity of the company.
B. Story sizing can vary from one team to another. Velocity depends upon the way stories are sized. Velocity should not be compared between teams.
C. If a Team is working on more complex tasks, we should expect a lower velocity.
D. We should look at the performance of individual Developers and work to improve the skills of the ones that are delaying the team.
E. Some of these teams may be new, after some Sprint they should also do 45-50 points per Sprint.

View Answer

Answer: B

Explanation:

Velocity cannot and should be not be compared between two teams. The interpretation of the story points, size of items belongs to one team. There is no such thing as a Good Velocity or a Bad Velocity. Remember, it is based on relative estimations. Comparing velocities between teams is an anti-pattern and can affect the transparency of estimates within the team. Velocity is the amount of work, measured in story points, completed by the team in a single sprint. Velocity is frustrating because it is often used inappropriately. Teams that are new to Scrum will assume that velocity represents the team’s productivity, and this is not the case. If a team allows this misunderstanding to go uncorrected, there is a danger that they will be asked for ” … a report that compares velocities between teams". Different teams will have different expertise, different experience and different team objectives. This is all reflected in the teams’ velocity making it unique for each team. So attempting to compare velocities between different teams is to compare different units of measure. The velocity is exclusively owned by the Developers. It merely provides the team itself and the Product Owner with an indication of how much work can be done within one Sprint. Leave the velocity at the Developers. You already know what the costs are; you know the composition of the team, you know how long the Sprint takes, so you can calculate the costs per Sprint per team. If you wish to compare, compare based on value, on the outcome, not on output. Standardizing the Story Points across teams is not a good idea either. When Teams know their success or compensation depends on a metric or a report, they may feel tempted pushed to game the system to not be seen as losers or just to get the prize. For instance, they can easily inflate the estimates to show a higher velocity. In such a system, the team will focus more on producing good numbers for the ones that observe them rather than focusing on generating value.