Scrum Team Velocity – Is it a Stick or a Carrot?
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.
A colleague recently reached out for suggestions to help a new client whose teams are having trouble adapting to using story points.
Here are 10 tips to keep in mind when helping teams in their transition:
Change the Language – Are We Estimating Effort or Estimating Size
Story points are intended to reflect relative size. And while they are loosely correlated to effort (e.g., the bigger something is, the more effort it takes to do it), they are not meant to represent a precise measure of effort.
If your teams are grappling with estimating-in-story-points, try changing your language to sizing-in-story-points. It’s a subtle difference for those of us familiar with the concepts, but can ease the transition for those new to it.
Create New Language – Stay Away from Numbers
Historically, we think of size in terms of how-long it will take to do it. Break that strong association by using a non-numeric, relative scale such as t-shirts, dogs, boats, planes, fruits, vegetables, candy, or planets.
Clarify Language – Are We Talking Effort or Duration
Let’s take a simple example…..I have a friend who can drive across country in 3 days by herself. It takes me a week. Assuming we’re taking the same route, and driving the same speeds, why is there a difference? It turns out that my friend can drive 12-13 hours a day with minimal stops. Whereas I start falling asleep after 2-3 hours and have to stop frequently. So it takes me longer (duration) to do the same amount of work (effort).
Duration is the time it takes to complete something from start to finish and is stated in “duration-units” such as hours, days, weeks, or months. Work (effort) is the amount of work required to complete something and is stated in “work-units” such as man-hours or man-days. Because these both have a “time” component, we often mingle them together inappropriately, causing problems if there’s not a clear, shared understanding.
For instance, when I estimate a task to be 40 hours, what I mean is “it will take me 40 man-hours to do this, if I have the information and decisions I need in a timely manner, if tools are available when I need them, and if I’m not working on anything else”. What others often hear is “it will take someone a week to do this”. I’m talking about effort; others are hearing duration.
The teams my colleague observed used the following definition when estimating their stories:
1 SP = 3-4 days
2 SP = 1 week
3 SP = 2 weeks
5 SP = 4 weeks
8 SP = 6 weeks
They are tracking actual hours worked on each story and are expecting that a 2-point story equates to a consistent number of hours. But their definition is expressed in duration-units rather than work-units, and the actual effort to complete a 2-point story can vary widely depending on whether one person can finish it in a week or it takes 4 people to complete it.
Don’t define story points in duration-units and expect it to correlate to effort.
Skip Estimation, Go Directly to Work
If your teams are thrashing because of estimation, then don’t estimate. Use commitment based-planning and have them track their story throughput rather than points or hours. As they become more comfortable with this, stories will begin to creep smaller and smaller naturally. Check out more about the #NoEstimates movement.
Compare to a Baseline
Have the team select a story that is representative of the type of work they do, assign a size to it, then compare all other stories relative to the baseline.
Practice Often
The more the team does what’s uncomfortable for them, the more practice they get, and the better they will get at it. Opt for shorter iteration lengths, as this will offer more opportunities to practice.
Value First
If teams are thrashing, there may be too many changes happening at once for them to absorb. We’re looking for the creativity and speed that comes from being on the edge of chaos, not in the middle of it.
Focus efforts on improving the ability to create vertical slices of value.
Then Flow
Once teams can craft valuable slices, focus on reducing the variability in story sizes rather than thrash about estimating. Strive for small stories using story-splitting techniques. Smaller slices are easier to size, easier to finish, make mistakes visible sooner, and allow for quicker feedback. Smaller stories also improve the flow of work.
As stories become small, uncertainty and dependencies decrease, and effort and duration can be good approximations of each other. A rule-of-thumb is a story should be small enough to be completed in less than 1/3 the length of your iteration, e.g., no longer than 3-4 days in a 2 week iteration. Mature teams will often have stories that take around one day, and all their stories are of similar size.
Remember – it’s the Conversation that’s Important
The magic about relative estimation is not in getting to an answer, but in the conversation that leads to shared understanding.
And…don’t Over-Stress the System
No matter what anyone thinks, pressuring a team to accept 800 hours of “planned” work when they only have 500 hours of capacity is not reasonable, and it will never work. Forget the “if you challenge them, they will rise to the occasion” call to arms. After a certain point, that’s just a bunch of malarkey.
As my grandma used to say, “You can’t get blood from a turnip”.