In my previous post entitled “Velocity, a measure that is false!”, we’ve covered bad ways of using the notion of velocity.
Here’s an excerpt:
In Scrum, **velocity** is the number of story points “done” during a sprint (and “done” depends on the definition formulated by the team).
It is an indicator used to help development teams during their sprint planning sessions. In fact, it allows to assess the quantity of work they can select for an iteration. This indicator can be used by the Product Owner to plan deliveries provided that the associated cone of uncertainty is taken into account.
How are teams using velocity?
A mature Scrum team selects, from the product backlog, the product backlog items (PBIs) that they plan to execute during the sprint because they are “ready”.
Let’s recall that, in Scrum, the development team is at the service of the Product Owner (PO). Therefore, when selecting the PBIs, the team seeks to deliver as much business value as possible while taking the context and constraints into account. They take care to put different aspects into perspective (i.e., value, date, risks and dependencies).
To make their selection, the Scrum team discusses with the PO. It is then that comes into play the team’s knowledge of their velocity, which is expressed in average value associated with a confidence interval (or cone of uncertainty).
Indeed, how does a team can determine when to stop? How many PBIs can they choose for the sprint?
Well, by using their velocity plus good horse sense. If the team historically carries out an average of 22 points per sprint (± 3), they should start asking themselves questions when they reach 20 points. “Can we take one more PBI? Should we stop here? Why? What would it take for us to take one more item? What would be the risk of taking another item? What would be the benefits?”
That’s often at that time that we discover the “race for story points” I’ve mentioned in my previous post…
A team who is mature manages to get out of the dynamics to make as many points as possible to use velocity as a tool to initiate discussions. Discussions between team members as well as with the PO.
During these conversations, the Scrum Master should pay attention to the team’s arguments. Is the team using arguments to protect themselves? Are they taking into account the decisions made during the retrospective and their influence on the current sprint? (The iteration begins at the very first minute of the sprint planning session.) Has the team reviewed their “definition of done” (DoD) and considered the impact on the current sprint? Etc.
Let’s come back to our team carrying out an average of 22 points. For the current sprint, they plan to perform 20 points, since the value of the PBIs they selected is collectively interesting. The PBIs also meet the sprint’s objective, leave room for bringing about the improvements planned, and take into account the improved DoD that now provides for a video user aid at the end of each sprint.
When velocity is used in such a way by the development team, the PO can use it as a planning indicator for the delivery. Therefore, it is judicious to have a delivery plan.
Suppose that our PO decides to have 4 releases per year, he will have to decide what he wishes to deliver to the users every 3 months. Together with the team, he will establish a release plan.
To ease the plan development, first, the team will estimate the PBIs. Then, taking into account the average velocity for a pessimistic story (average of the 3 to 5 worst velocities recorded), the PO will draw a line over which he will order the product backlog items. This will allow him to conduct the arbitrations required to have a product that is complete and coherent at all times.
The release plan will be updated during each sprint review, taking into account the updated velocity indicator. Thus, it allows, at the end of each sprint, to inspect and adapt the product backlog and redirect efforts.
At this point, it is crucial to consider the following: Is the definition of “done” really complete? Does it really allow to ensure that ALL work required to release the software is done. If it’s not the case, your velocity indicator is erroneous!
A trick in such a case is to add, at the end of each sprint, a PBI containing the work remaining to be done for the release and to estimate the effort required. This PBI is inserted right above the line (based on the one selected: pessimistic, average, or optimistic), thus moving under the line the planned items.
This way of doing allows us to make choices regarding the items to be executed (those that we wish to see above the line) and to make visible the work to finish before the release; work which unfortunately has low business value.
This mean allows us to rely on the team’s velocity to perform our planning.
It is yet important to be aware that if your definition of “done” is not complete, the PO cannot decide to release earlier even though he has a business opportunity. However, this is another subject that could be covered in another post…
Based on my experience, I can say that the way a team takes their velocity indicator into account is a good indicator of their maturity.
And this concludes the use of velocity—an indicator of the team for the team—that is usable by the PO.
What is your plan for helping your team to go from velocity a “performance measure” to velocity a “decision support”?