The average velocity of a team is obtained by averaging the sum of user story points accumulated by the team at the end of each iteration (or cycle).
But what do these points precisely represent? In Agility, there are two different types of points that it is important not to mix up: business value points and story points. The latest are the ones used by teams to calculate their velocity. Story points are estimated by the team during the sprint planning session that is held at the beginning of each iteration.
What are story points exactly? They are complexity points. Well, they are more than that. They also cover the team’s execution time as well as the risks related to the story. To include all three facets, many like Mike Cohn in this article talk about effort points. For instance, with equal risks, a story that is very complex, but that does not take a long time to be done could obtain the same number of points as a story that is both simple and lengthy. Why? Because it’s the total effort required to be deployed to complete the story that is being assessed, and not just one of these aspects.
A card game based on the Fibonacci sequence is commonly used to assess complexity; it’s called Planning Poker®.
Certain people use other evaluation methods such as Affinity mapping or T-shirt sizes (XS, S, M, L, XL, XXL). The important is that it is meaningful to your team and that you master the method that is being used.
Finally, the number of points accumulated by a team is not to be used to draw comparisons with other teams. This number is unique to each team. The variance in teams’ velocity depends on many factors:
- The skill level of the team members
- Their experience
- Their knowledge of the business field
- Their working methods
- The blockers and risks faced.
Therefore, one cannot say that a team with an average velocity of 40 points is better than another one with 25 points. The good reflex of a Scrum Master or manager is to question what prevents the team with 25 points to reach a velocity of 40 or more and to do what is possible to increase their velocity while maintaining a sustainable and sustained pace.
The Planning Poker® game in 7 steps
Planning Poker® is the most common Agile technique that allows to establish the “size” of each story—taking into account time, risk, complexity and any other relevant factors—during the iteration planning meeting.
Let’s play Planning Poker®:
- During the iteration planning session, the Product Owner (PO) presents the user stories to the team.
- For each story, team members ask their questions to the PO to make sure they understand well the need expressed.
- Once all questions have been asked and answered and all risks as well as the story and its complexity level seem to be well understood by all team members, it is time to estimate the effort by voting using numbered cards, which are based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.).
- How do we select the card to play? Using benchmarks: a story given 5 points should normally be twice more complex than a story given 2 points.
- What do we do when we do not have any comparison standard? Estimates are then based on the team’s best knowledge at that precise time. That’s why that, at the beginning of an Agile Lean or Scrum implementation, a few iterations are required to stabilize velocity and to establish benchmarks.
- When everybody is ready with an estimate, all cards are presented simultaneously (this is very important not to influence the votes of one another).
- Sometimes, a consensus is reached on the first turn. When there is a consensus, the number of points is recorded and we move to the next story. Otherwise, the person with the highest score has to explain their choice to the team, and so does the person with the lowest score.
- Once the explanations are provided, we can have discussions to try to rally everyone to a common “size”.
- Unanimity is required. Therefore, discussions continue, and we repeat steps 4 to 7 until consensus is reached.
Those who are using and promoting the Planning Poker® game generally see the following benefits:
- Collaboration is fostered since the entire team is committed.
- A consensus is reached regarding the estimation instead of having a “champion” offering some simple advice.
- It allows to outline and discuss problems and risks when the story is being presented.
- It’s not the managers who are voting, but those who will actually be executing the stories.
- Discussions regarding the implementation are interrupted before digging too deeply.