What should your team do?

You are part of a team with an average velocity of 55 points per Sprint. Another team of the same size working on the same Product has an average speed of 105 points per Sprint.

What should your team do?
A . Do nothing.
B. Add additional Developers to get more work done.
C. Check both teams’ estimates to see if one team is inflating estimates or if your team is underestimating.
D. Check if your team is receiving more difficult tasks than the other team.
E. Work overtime.

View Answer

Answer: A

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.