Velocity, the measure of total story points completed in a sprint, is often misunderstood, and used as a “stick” against teams rather than a “carrot”.
I was once asked about trying to prevent a dip in velocity during team member vacations. Today I saw a post in LinkedIn titled “Tips and Techniques for Maintaining Velocity during vacation times”. The very question of how to keep velocity the same during vacations represents a gap in understanding of both why we use velocity and what velocity is measuring. Velocity is expected to dip when team capacity drops. Otherwise, we are falsely trying to use velocity as a prediction of what can be accomplished in a sprint. Where “management” stresses the need to have a steady velocity regardless of what is going on in a given sprint, it is like using a “stick” to motivate the team. It also encourages “gaming the system”, creating a false sense of security and velocity. We use delivery of quality software as our main measure of success. We use velocity to predict how much work we can commit to in order to become reliable, predictable, and consistent.
Most teams use points to estimate stories, the number of points completed is the teams velocity. The goal is to become predictable and consistent. Velocity is not normalized across teams, and cannot be compared across teams. Once you realize this fact, then it is easier to accept an explainable dip in velocity. Note: If you are following SAFe (Scaled Agile Framework) and trying to normalize points see http://www.scaledagileframework.com/iteration-planning/ In Safe, a 1-point story is normalize, but story points vary from there. A SAFe teams’ velocity should not be compared to any other.
Given a team has been together for at least five sprints, and story points are being used for relative sizing of stories in a consistent fashion, the team’s velocity will begin to stabilize. Good Retrospectives will provide insight into improvements activities that may help increase the team’s velocity a point or two each sprint.
With a stable velocity and team, we can predict what velocity can be achieved for any sprint. If Monday is a holiday, or if one team member is on vacation for the entire sprint, ScrumMasters can help guide the team to not over-commit. Thus supporting a sustainable pace, and exhibiting the true value of velocity as a measure.
Let’s take a look:
Team Wolf
Team Wolf has 6 members, and a velocity of 40 for a two week sprint. I calculate capacity (the number of hours available to work in a sprint) at 6 hours per person, per day. For Team Wolf, a 10 day sprint has 360 capacity hours.
One bank holiday during a sprint
Capacity is 324 hours, (6 * 6 * 9) resulting in a 10% lower number of hours in which to complete the sprint’s work. I would encourage the team to commit to approximately 10% less work and aim for a velocity of 36 points.
One member on vacation for the entire sprint
Capacity is 300 hours (5 * 6 * 10) resulting in a 17% lower number of hours for a sprint. I would encourage the team to commit to approximately 17% less velocity, or 33 points.
Velocity dips can happen anytime for a number of reasons. A planned dip is not something to beat a team up over. Achieving the teams’ committed velocity is an excellent carrot. Reward teams, and celebrate successes.