As a framework for software development, Agile emphasizes teamwork in software development and recognizes its human aspect. Delivering innovative, high-quality software at a steady pace requires motivated, involved, and happy teams. The happiness metric was developed to measure happiness as an indicator of team well-being. The assumption is that happiness is strongly correlated with team well-being. So, a happy team will also be more efficient, more cohesive, more ready for the tasks, and deliver higher quality software. If people are unhappy, something needs to be done. After all, team well-being is what we are really interested in.

However, the usefulness of any measure depends on how well it captures actual team well-being and provides realistic venues for improvement. Although it’s certainly an excellent start, I believe that the happiness metric is sub-optimal at best.

At first glance, a question like ‘How happy are you right now with..” might seem sensible. But take a moment to reflect on what ‘happy’ means, exactly. How would you interpret this question? I’m sure many people will have wildly different interpretations of ‘happy’.

Does happy mean that you’re smiling all day? That you jump out of bed in the morning, happy for another day of work? That you are just ‘ok’ most of the time? People will have different interpretations because ‘happy’ is a very subjective state of mind. Different interpretations will lead to a different meaning of the responses to these kinds of questions. It’s like comparing apples and oranges. The question is too subjective, it allows multiple interpretations, giving different meanings to the responses.  

Although happiness is certainly important, a Scrum Team can benefit more from a task- and team-oriented measure that does do justice to the nature of the work environment. What is it that we really want to know as a Scrum Team?

Read the full article here.