Matt Mohan

The Lottery Ticket Metric: A Better Way to Measure Team Health

Every software engineering manager and Scrum Master wants to know: How is the team actually doing?

We track metrics like velocity, lead time, and ticket throughput, but we all know those are output metrics. They don’t tell us how close the team is to burnout or who is about to hand in their notice.

To solve this, teams often turn to subjective surveys or retrospective polls; however, standard scales are notoriously noisy. Here is a story of how a casual joke during a retrospective led to one of the most reliable team-health metrics I’ve seen employed.

The Subjectivity Trap: The 1-5 Scale

Years ago, I worked with a Scrum Master who was deeply committed to managing burnout and reducing churn of team members. As part of our bi-weekly sprint retrospectives, they began tracking team happiness using an anonymous Google Forms poll and a simple 1 to 5 scale.

It was a well-intentioned exercise, but we quickly ran into the subjectivity problem:

  • Optimization bias: A natural optimist’s “3” is very different from a pessimist’s “3”.
  • Temporal noise: A bad morning commute or a cold cup of coffee could easily tank someone’s score for the sprint, even if their overall job satisfaction was high.
  • The “safe middle”: Most team members fell into a comfortable, uninformative routine of reporting “4” or “3” to avoid drawing attention or sparking an awkward discussion.

Over time, we realized this 1-5 measure was only useful for identifying immediate, sprint-over-sprint spikes in frustration, and even then the numbers would obviously jump when the team pessimist was at the dentist and sink when the eternal optimist was sick. It was too noisy to act as a true proxy for long-term job satisfaction or risk of team members leaving.

Then, the lottery happened.

The Pivot: “How much would it take?”

One day, as we were walking to a meeting room for our retrospective, two team members were quickly discussing who was going to pick up tickets for their lottery pool. The jackpot had hit the maximum (at the time) $60 million and the team members didn’t want to miss out.

Overhearing this, our Scrum Master had a flash of inspiration. Instead of asking for our usual 1-5 happiness score, they asked this:

What’s the minimum lottery win it’d take for you to quit tomorrow and leave the team?

Suddenly, the abstract question of “happiness” was replaced by a concrete, tangible decision.

We went around the room and gave our numbers. At the time:

  • Everyone agreed that the night’s $60 million would be enough to leave and pursue their own passion projects, travel, or retire.
  • Surprisingly, the majority of the team stated they wouldn’t leave for less than $10 million, a fairly significant sum.

This was a massive testament to our team’s health. It meant people genuinely liked the work, their teammates, and the project enough that they required life-altering amounts of money to walk away from it.

The Scale of Team Health

What started as a fun retro icebreaker quickly evolved into a core metric. By anchoring job satisfaction to a financial figure, we created a scale that had actual meaning.

Over the following months, as team health waxed and waned, we watched the numbers shift, leading to a better understanding of team dynamics. For instance, when our team lead left and projects stalled, the metric dropped to about 12 months of salary—a clear sign that team members were weighing their options.

The “Free Play” Red Flag

My absolute favorite feedback from this metric—and the ultimate red flag—came during a particularly grueling project phase. One dark winter afternoon, after weeks of effort for a project that seemed doomed to never-ending scope creep and “Go-No Go” calls that ended in “No-Gos,” one team member admitted:

At this point, if I won a free play ticket on my next lottery draw, I’d probably take that as a sign from the universe to leave and do something else.

When your team members tell you their price is a $5 lottery ticket, you don’t need a complex HR survey to tell you you’ve got a critical retention risk. It meant the frustration had crossed the threshold where leaving was worth it even without any financial safety net.

Why the Lottery Metric Works

If you are thinking of trying this with your team, here is why it works so much better than traditional happiness surveys:

  1. Anchoring: Rather than asking for a rating of a subjective feeling (“happiness”), it asks for the value of an exchange. It forces the developer to weigh their current daily experience against their financial independence threshold.
  2. Actionable Trends: When someone’s number drops from $15 million to $1 million over three sprints, it’s a clear signal to check in. It bypasses the “everything is fine” response.
  3. Humor as a Safe Space: It’s easier and less confrontational to joke, “My number is down to a free play this week,” than it is to look your manager in the eye and say, “I am burning out and thinking of quitting.” It gives the team a low-friction vocabulary to signal distress.

Using it Safely

If you decide to adopt this metric, a few rules of engagement are essential to maintain psychological safety:

  • Keep it anonymous if needed: In a low-trust environment, team members might feel pressured to say “$100 million” to appear loyal. Let them submit their numbers anonymously or use it strictly as a team-wide aggregate.
  • Never hold low numbers against anyone: If a developer says they’d leave for $500k, that is an organization and leadership problem to solve, not a performance issue.
  • Pay attention to the trend, not just the absolute values: Some people naturally have lower financial thresholds. Look for relative drops in a single person’s number or a downward trend across the team.

Next time your sprint retro feels a bit stagnant, skip the 1-5 rating. Ask your team what their lottery number is. You might be surprised at how quickly it clarifies the real state of your team’s health.


Matt Mohan

I’m Matt, a software engineer based just outside of Toronto, Canada. This blog is mostly an excuse to (re)build sites with different web tooling and compare their relative merits