Happiness Metric

”Carnation Condensed Milk, the milk from contented cows.” — Advertising slogan, Carnation Milk Company, 1907

… you have a Community of Trust and have a common Vision. The Scrum Team is an Autonomous Team. You are holding regular Sprint Retrospectives to increase velocity and other traditional measures of value and potential to generate value.

✥      ✥      ✥

 In reflection and other self-improvement activities, there are generally many ideas for improvement. But you often don’t know in advance which improvement activities will produce great benefits, and which will not.

The pattern One Step at a Time recommends focusing on a single improvement, so that the effects of an improvement activity are clear. But there are many opportunities for improvement, and you need a way to work on the things that are most likely to have a significant benefit.

It is natural to come up with long lists of things are supposed to help improve velocity. Because there are so many, it’s possible that you are working on the wrong thing; the improvement selected will not actually improve velocity at all, and if it does, it is likely not the biggest or most important improvement.

People often feel disconnected to these long lists. So they will not be motivated to make them work.

So you need to work on the right improvement, and the team must feel some passion about the improvement.

People derive great satisfaction from doing their job well. Associated with this, most people have a strong sense of responsibility toward their jobs, particularly if they are in an Autonomous Team.


Find out what one improvement will increase the happiness of the team the most, and implement that improvement in the next Sprint.

Typically, the team decides what its current happiness level is and then asks each team member to express what would increase their happiness the most. As a team, decide what one improvement will produce the greatest happiness improvement for the team as a whole.

✥      ✥      ✥

There are various ways of measuring the team’s happiness, but we have found that a simple subjective five-point scale works well. You don’t need to be fancy.

The desired improvement may become part of the Sprint Goal.Thus in some sense, this pattern can help create the Sprint Goal.

There is a certain vulnerability in the expression of these wishes. Some people might feel uncomfortable doing it publicly. In this case, they could be submitted anonymously. However, this is not ideal: it is much better to strengthen the Community of Trust so that people feel comfortable sharing their wishes publicly.

It turns out that focusing on the happiness of the team has an uncanny ability to uncover the issues that make the team more effective, not just happier. This is probably because people generally derive great satisfaction from doing their job well. In addition, they are often in a good position to understand what things can make them more effective, and what things are standing in their way.

Another reason that the Happiness Metric results in team performance improvement is that people feel more personally connected to and committed to the improvement. They can see how it will impact them personally, so they are more likely to work harder to accomplish the improvement.

The Happiness Metric can help prevent burnout. Burnout occurs when people work long hours or spend much mental energy over an extended period without any respite. They just get tired of the pace. Burnout can kill productivity through less work later (“Every hour of overtime is offset by an hour of undertime” — Tom DeMarco) or by people leaving to find a more sane environment. If burnout is threatening, someone will likely request as their Happiness Metric to “stop the insane work hours.”

People may have different perceptions of happiness. So it is important not to let a single person’s happiness metric dominate, but rather it is a team decision to find what is best for the team. At the same time, every person needs to be heard, so they feel part of the final decision.

Some people (such as old-time managers) may fear that the team could “game” the system; deciding that their happiness could best be improved by taking every Friday off, for example. Of course this is possible. Like all aspects of team autonomy, one must trust the team to follow the The Spirit of the Game. (And if you don’t trust the team, or if the team violates the The Spirit of the Game, you have much bigger problems on your hands!)

Note that with all improvements, Happiness Metric improvements must be measurable (Testable Improvements) — you need to be able to tell whether the improvement is actually being done.


A team uses the Happiness Metric as a way to identify and prioritize process improvements. On a scale of 1-5 they ask (1) how do they feel about their role in the company and (2) how do they feel about the company. Then they share what would make them feel better and the team uses planning poker to estimate the value of things that would make team members feel better. The team estimated the value (as opposed to effort) of backlog items as well. The entire product backlog was estimated at 50 points of value.

“Better user stories” was the top priority improvement for the team. Removing this impediment was estimated at over 60 points of value. The Chief Product Owner wondered if removing that impediment might double velocity as the impediment value was higher than the entire product backlog value for the Sprint.

"Improve User Stories" was put into the Product Backlog and pulled into the next Sprint with a Definition of Done. This Definition of Done was implemented as acceptance tests that had metrics that were calculated at the next Sprint Review. They included:

  1. How many stories got into the Sprint that did not meet the INVEST criteria (immediately actionable, negotiable, valuable, estimable, sized to fit, and testable)? — should be 0
  2. How many times did developers have to go back to the product owner to clarify a story during a Sprint?
  3. How many times did dependencies force a story into a hold state during a Sprint?
  4. How many stories had process efficiency of over 50%? (process efficiency = actual work time/calendar time)
  5. How many stories were not clear to developers? Measure by number of teams members that complained about a story.
  6. How many stories implied technical implementation rather than clarifying desired user experience?
  7. For how many stories did developers understand the linkage between the story, the theme that produced the story, the epic that generated the theme, and the business need that generated the epic? Measured by number of team members complaining that they did not understand why they were doing a story.

Resulting Context:

While improving the quality of user stories is never ending, the Sprint Review demonstrated significant improvement on this backlog item as measured by the acceptance tests. Significant improvement resulted in an increase in velocity after several Sprints. After velocity had doubled this impediment fell off the top of the impediment list and another impediment took it’s place.

The first graph below is team happiness data for weekly Sprint 140-212 where the dark green line is happiness about the individual's work and the light green is happiness about the company. The second graph shows the velocity of the team. In Sprint 86 the team was doubled in size. By Sprint 89, “Improve User Stories” was put in the backlog of each Sprint. Within three Sprints velocity more than doubled. By Sprint 211 the team had tripled in size with output up 1200%, the first documented and substainable non-software hyperproductive team. The low points on the velocity graph are where the company was on holiday.

Source: Scrum Inc.

Happiness Sprint 140-212. Source: Scrum Inc.

This pattern has a cool generative quality, where the application of the pattern indirectly generates the desired outcome. As teams succeed in improving their productivity while increasing their happiness, the success will build on itself, driving further productivity, happiness, and enthusiasm.