January 9, 2018

Over Thinking Velocity in Scrum

  —A model of velocity in 6 months.

I’ve reached the point where I have enough data to calculate a meaningful velocity for my team. I defined velocity as the median of the story points completed in each sprint during the last six months.

I use the median because its a more robust statistic than an average. By robust, I mean it changes more slowly and is less susceptible to outliers.

I am concerned how this model will work for us, particularly when it involves schedule projections. I collect six months of data to permit a four month projection. (Using six months of data is an arbitrary decision.)

I present the velocity during the sprint planning meeting as guidance. As guidance, I acknowledge that velocity is a model of team capacity. The team may have reasons to plan for more or less work.

I didn’t count on people’s reactions to this model. They challenged it

• using individual and team absences.

  A median accounts for things like statutory holidays, vacations, and student turn-over. Absences make the median lower than it would be if everyone were present.

  The model doesn’t address extremes. A holiday shutdown (and the resulting velocity) can be excluded.

• using the accuracy of the story point estimates.

  Using powers of 2 to estimate story points and a median makes the calculation conservative, not aggressive. Mitigations for poor story point estimates include swarming and point changes until story is added to a sprint.

• pointing out that adding people didn’t change the velocity.

  A median taken over 13 sprints with team of 8 doesn’t move much when someone is added or removed from the team. These changes won’t affect velocity for at least 6 sprints.

  This is a benefit when dealing with students who change every four months. It is a disadvantage when you add or remove a full time person and management can’t see the impact immediately.

People didn’t buy the argument that the model accounts for absences. If you have a statutory holiday once a month and run two sprints each month, then the velocity of both sprints includes the reduced capacity introduced by the holiday.

I agree vacations during the holiday season introduce more pressure on velocity. In my environment, people tend to take more vacation during the summer and in December. Fewer people means less capacity and smaller velocity. If fewer people results in more velocity then other challenges exist.

The absence argument is hard to explain since velocity is presented as guidance. This argument implies people didn’t percieve velocity as guidance or felt that they weren’t empowered to use this information.

Poor estimates are challenging. In our case, the team provides estimates and can change them at any point up to commitment into the sprint. I say this, because adding a story to a sprint is a commitment to deliver it.

The method used to generate story point estimates and velocity is conservative and should buy the team additional buffer for poor estimates. When using powers of two for story points, any debate on the story points that can’t be resolved should drive the story point estiment to the next higer powe of 2. This implies that every situation like this introduces up to 100% buffer into estimate.