Gaming Velocity

Imagine your team’s line manager insists that a successful team improves velocity regularly. How could you, as a team, satisfy this strange, unsuitable demand without working more? How can you make gaming velocity a reality?

I run this exercise with my students of entry-level Scrum Master and Product Owner classes to help them reflect on the tricky nature of measuring success, metrics, and, of course, Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”

For the following article, I aggregated suggestions from more than 50 classes on how to “best” game velocity.

Why Velocity Is a Problematic Metric

Before we jump to the suggestions, let us analyze why velocity is a tricky metric:

• Team-specific nature: Velocity is inherently specific to each team, influenced by their unique estimation practices, work processes, and individual skill levels.
• Misleading comparisons: Using velocity to compare different teams can be misleading, as higher velocity does not necessarily indicate higher productivity or efficiency.
• Different definitions: Each team may define story points differently, invalidating cross-team comparisons.
• Counterproductive behaviors: An overemphasis on velocity can lead to inflating estimates to boost numbers or focusing on easy tasks rather than delivering real value.

Lastly, relying on velocity for broader comparisons or performance evaluations undermines Scrum’s core principles and can harm team morale and effectiveness.

Consequently, a team should use velocity — if at all — internally to help plan and track progress.

The Gaming Velocity Exercise

The scenario is as follows: Your team’s line manager is convinced that a successful Scrum Team in software development steadily increases its velocity Sprint after Sprint. Your task as a team is simple: Identify ways that allow a Scrum team to report a regular increase in velocity without working more at the team member level.

Gaming Velocity for a Regular Increase Without Increasing Your Workload

Now let us have a look at 13 ways of gaming velocity:

Estimate and Re-Estimate Story Points

• Systematically increase the estimation of items from Sprint to Sprint.
• Re-evaluate and increase the story points of past completed items.

Split User Stories

• Break down larger items into smaller ones and assign higher story points to each smaller part.
• Divide existing work items into even smaller parts, creating more granular tasks.

Include Non-Development Work

• Count bugs and fixing technical debt with story points.
• Factor in the complexity of completed research by assigning story points to spikes or research tasks.
• Include routine maintenance or administrative tasks and estimate them.

Gaming Velocity by Creating Dummy or Fake Tasks

• Add dummy tasks to the Sprint that do not require actual work.
• Invent tasks that are not essential to the product but can be completed quickly.

Automate Regular Tasks but Report Them as Manual

Automate repetitive tasks but report them as if they were manually completed.

Adjust the Definition of Done (DoD)

• Lower quality standards or relax the DoD to complete items faster.
• Adjust the DoD to include more tasks as done, even if they are not fully completed.
• Simulate technical debt when completing tasks.

Extend Sprint Duration

Quietly increase the duration of Sprints, resulting in higher reported velocity.

Overlapping Sprints

Work on tasks that span multiple Sprints and count them towards all Sprints.

Adjust Velocity Calculation

• Change the method of calculating velocity, such as using a rolling average over fewer Sprints.
• Include buffers or contingency points in planning that appear as additional velocity when not used.

Focus on Easy Wins for Gaming Velocity

• Prioritize simpler tasks that can be completed quickly and easily.
• Choose only easy work items to ensure quick completion.

Report Unfinished Work as Complete

Mark unfinished tasks as complete to boost the reported velocity.

Create Stories From Minor Tasks

• Build work items out of insignificant tasks to increase the number of completed items.
• Turn trivial tasks into stories and estimate them.

Task Recycling

• Reintroduce tasks that were already present but unestimated in previous Sprints.

A Note of Caution: While these methods can technically inflate reported velocity, they may compromise the integrity and transparency of the Scrum process. Considering the long-term impact on team morale, product quality, and stakeholder trust is crucial. Ideally, it would be more beneficial to discuss and align expectations with stakeholders about realistic measures of Scrum success—such as delivering valuable Increments and maintaining a sustainable work pace.

Don’t undermine Scrum’s core principles instead!

Additional Considerations Regarding Gaming Velocity

While velocity can be a valuable metric within the context of a single team, it’s important to understand its limitations and use it wisely. Here are some additional considerations:

1. Context matters: Velocity should always be interpreted in the context of the team’s specific circumstances, including team size, experience, and the nature of the work being done.
2. Complementary metrics: Relying solely on velocity can be misleading. Complement it with other metrics like customer satisfaction, quality of deliverables, and team morale to get a holistic view of team performance.
3. Focus on outcomes: The ultimate goal of any Scrum team is to deliver value. Focus on outcomes and impacts rather than just output. High velocity without valuable deliverables is meaningless.
4. Continuous improvement: Use velocity as a continuous improvement tool rather than a strict target. Reflect on fluctuations and understand the underlying causes to improve processes and efficiency.
5. Communication and transparency: Ensure that all stakeholders understand the nuances of velocity. Clear communication can prevent misunderstandings and unrealistic expectations.
6. Avoid pressure: High pressure to increase velocity can lead to burnout and decreased quality. Maintain a sustainable pace and prioritize the well-being of team members.

By considering these considerations, teams, and organizations can use velocity effectively while avoiding the pitfalls of “gaming” the metric.

Conclusion

While velocity is helpful for internal team planning and progress tracking, it becomes problematic when used for serious applications such as comparing different teams. The exercise I conduct with my students demonstrates how easily velocity can be manipulated, revealing the pitfalls of over-reliance on this metric. Goodhart’s Law states, “When a measure becomes a target, it ceases to be a good measure.” (See above.) This is particularly true for velocity, which can drive teams to engage in counterproductive behaviors, such as inflating estimates and focusing on low-effort tasks.

Ultimately, velocity should remain a tool for internal use, guiding a team’s progress without becoming a benchmark for performance comparisons. By understanding its limitations and potential for misuse, organizations can avoid the trap of “gaming velocity.” Instead, focus on delivering actual value.

Nevertheless, the exercise is a good thought experiment that discusses the nature of measuring success. By the way, when I play the game with managers, they know how gaming velocity might work.

How are you measuring your team’s success? Please share with us in the comments.