Your browser does not support JavaScript! Six Signs your Team’s Acceleration is Too Good to be True - Scrum Inc.
  • LinkedIn
  • YouTube
  • RSS

Let me say right from the beginning that I am a huge fan of tracking velocity in Scrum…it is an amazingly powerful concept.

  • The ability to measure team output from sprint to sprint allows a team to systematically experiment with different process improvements and consistently get better over time.<
  • A clear sense of how much output the team actually produces within a sprint also drives better decision-making about when to expect project completion without slave-driving the team developing it.
  • As an agile leader, I like to know whether my teams are accelerating, decelerating or staying stable over time. If they are accelerating, it gives me confidence that our projected completion dates are relatively safe; whereas if they are stable or decelerating, it implies greater risk in current projections.
But metrics are only as good as the integrity of the data that feed them. The traits that makes estimating velocity in points so powerful (speed, ease for the teams, intuitive accuracy of estimation) also mean that, in the wrong conditions, velocity can be manipulated to produce misleading conclusions.  To be clear, this is not the terrible scourge that proponents of measuring in hours often claim it is…a few simple guidelines such as “NEVER tie incentives to velocity” and “don’t use declining velocity as a reason to beat up your teams” generally suffice to eliminate any deliberate gaming of the system. 
 
However, seeing velocity increase over time just feels good and teams often thrive on the sense of accomplishment that comes from getting more done in less time.  Even without overt pressure to increase velocity, the collective will to go faster can create upward velocity drift that isn’t necessarily driven by increases in underlying output.  Since only the team suffering from velocity drift is impacted, this need not be a major problem. But for Scrum Masters, Product Owners and teams concerned with maintaining the integrity of their velocity metric, I humbly offer…
 
The 6 signs that your beautiful velocity growth trajectory may just be bad data:
 
  1. Velocity always increases – Even the highest-performing Scrum teams suffer setbacks or encounter new impediments. In general, scrum teams that set challenging goals should expect to fail about 20% of their sprints, meaning that velocity should decline from the previous sprint about the same percent of time (if you are using “yesterday’s weather” to pull stories into the sprint). If your team has been through a dozen sprints without a single backslide in velocity, it suggests that stately upward trend is being managed more deliberately than it should.
  2. Inexplicable Acceleration – Velocity can go up in short bursts for no particular reason, but it is difficult to sustain structural velocity improvement without systematically removing team impediments. So if a team’s velocity has been increasing consistently but they can’t point to specific impediments that they have removed, that is a red flag that the acceleration may not be real. At best, the team is not conducting healthy process experiments to deliver repeatable and sustainable acceleration. At worst, they may be undermining the meaningfulness of their velocity.
  3. The same story now receives a higher point estimation than it used to – This is the definition of “point inflation” that opponents of measuring velocity in points are always pointing to. In practice, we rarely see egregious cases of point inflation where the exact same story that was 3 points in a previous sprint is now 5 points in the current one. Instead, we typically encounter more nuanced forms of inflation, such as when an additional quality check is added to correct for past issues and points are added to complete this additional work. The amount of effort needed to complete the work may have increased, but the amount of output has not, so these added points represent a subtle form of point inflation.
  4. Backlog stuffing with “filler stories” – Teams that are striving to increase velocity often become obsessed with ensuring that everything they do is reflected in the backlog. In general, you don’t want to do tons of off-backlog work and do want to stay focused on completing the goals of the sprint. However, some level of housekeeping and team hygiene work is a natural part of the group process. If including these items in the backlog was always a team norm…that is fine. If that wasn’t always the norm, then including these filler stories with associated points gives the false impression that the team is accelerating when it is not actually producing more output.
  5. Lots of separate minimum-sized stories – We often say that smaller user stories are better, and that ultimately teams should strive to work with uniformly small stories in the sprint. This is a great goal, but it can be taken too far. If work is broken into many stories that are smaller than the smallest sizing increment used by the team (“xs”, “1-point”, “Chihuahua”, etc.) then the rounding error of adding all these fractional stories together starts to exert a strong upward influence on velocity. If these precisely divided stories are still good user stories reflecting incremental functionality, then it is time to reset your reference story to accommodate smaller divisions. More often than not, however, these tiny stories are really tasks and are hurting the team’s ability to work together to produce quality product.
  6. – Tracking team strength in each sprint is helpful for knowing the context the team is operating within. There are a number of compelling reasons to apply a lightweight level of normalization to a team’s raw velocity number to get a better predictor of actual team output: it provides a more stable measure of output in the face of major illness, vacations, family leave and other significant shifts in team capacity. However, it also introduces one more lever that can artificially increase apparent velocity, so teams need to be careful to only reserve normalization adjustments for major capacity impacts, and not try to adjust for every perceived shift in team strength. If you notice that the team has not been at full capacity for a long time, it is time to questioning if over-normalization may be occurring.
Feel free to share your own experiences with velocity in the comments section below, or check out other musings on the value of good metrics in Scrum, including a thread on leadership dashboards here.
 
 
-Alex
 
 

Alex Brown is Scrum Inc.’s Chief Product Owner and Chief Operating Officer.  He set up the company’s internal metrics dashboard to automatically consolidate & share agile metrics and support better decision-making.  He also trains senior leaders and consults to companies on how to succeed strategically in an agile business environment.
 

en_USEnglish
Shares