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.
Ideally, a metric is a leading indicator for a pattern change, allowing your Scrum team to analyze the cause in time and take countermeasures. However, what if you picked the wrong metrics? What if these useless agile metrics lead you in the wrong direction while providing you with the illusion that you know where your team is heading?
Learn more about useless agile metrics, from individual velocity to estimation accuracy to utilization rates.
In their book Agile Retrospectives, Esther Derby and Diana Larsen popularized the idea that a Sprint Retrospect comprises five stages. The second stage refers to gathering data so that the Scrum Team can have data-informed Retrospectives.
As I have observed in practice, many Scrum Teams either limit the data gathering part of the Retrospective, thus lacking vital information. Or they invest too much time doing so, leaving little capacity to analyze the data and come to conclusions on how to best improve as a team.
Read on and learn how you can avoid falling victim to both scenarios by gathering data continuously and asynchronously.
Suitable agile metrics reflect either a team’s progress in becoming agile or your organization’s progress in becoming a learning organization.
At the team level, qualitative agile metrics often work better than quantitative metrics. At the organizational level, this is reversed: quantitative agile metrics provide better insights than qualitative ones.
