The happiness radar scores team satisfaction across multiple dimensions at the end of each sprint. Plot the scores on a radar chart and watch patterns emerge over time. Snap each sprint's radar and track the trend.
Run the happiness radar at the end of each sprint as a complement to the standard retrospective. It takes 10–15 minutes and produces quantitative data that makes team health trends visible over multiple sprints — something narrative retro formats can't do.
The radar is particularly valuable for teams that are hard to read in open discussions — some team members express satisfaction more readily than others, and the scored format gives quieter voices an equal weight in the data.
How satisfied is the team with the sprint process? Standups, planning sessions, reviews, retros — did they run smoothly and add value? Score 1 (very dissatisfied) to 5 (very satisfied). Low process scores often surface before the team can articulate what's wrong.
How well did the team work together? Cross-functional coordination, pair programming, knowledge sharing, conflict resolution. Collaboration scores are the leading indicator of team cohesion — a downward trend here predicts performance problems before they appear in velocity.
How satisfied is the team with the technical quality of what they shipped? Test coverage, code review rigor, tech debt accumulation, architectural decisions. Engineers tend to care most about this dimension — give it explicit space.
How satisfied is the team with the value of what they delivered to customers? Did the features solve real problems? Was the scope right? Product managers and designers tend to drive this dimension.
Overall morale, energy levels, sense of purpose, work-life balance. This is the top-level dimension that all others contribute to. A team can score high on process and low on health — which suggests the problem is something outside the process: workload, motivation, or culture.
Did team members learn new skills, tackle new challenges, or grow professionally this sprint? This dimension is easy to deprioritize under delivery pressure — making it explicit in the radar ensures it gets measured.
Draw a hexagonal radar with one axis per dimension. Mark 1–5 on each axis. Each sprint's scores will form a polygon on this chart. If you're running this for the first time, add a reference polygon showing the previous sprint's scores in a different color.
Each team member scores each dimension privately on a card or sticky: 1–5 for each. No discussion until all cards are submitted. Private scoring prevents anchoring on the first number someone says.
Average the scores for each dimension across all team members. Plot the average on the radar chart. If the scores are widely dispersed (one person gives a 5 and another gives a 1), circle that axis — the dispersion is more interesting than the average.
Focus the retro discussion on the two or three lowest-scoring dimensions. Ask: 'What happened this sprint in the [dimension] area that brought this score down?' The score is the prompt; the conversation is the value.
Snap the radar with BoardSnap after every sprint. The AI reads the dimension scores and outputs them as structured data. Over multiple sprints, the trend in each dimension becomes visible — and trend data is far more actionable than a single sprint's scores.
The happiness radar produces data over time. A single sprint's radar is interesting; four sprints' radars on the same board are revealing. The physical whiteboard lets you draw overlapping polygons in different colors to show sprint-over-sprint trends — a capability that digital retro tools handle awkwardly.
BoardSnap reads the radar structure — axis labels and scores — and outputs the dimension values as structured data. Over multiple snaps, the trend in each dimension tells the team's health story in a format that can be shared with leadership without the emotional complexity of raw retro feedback.
Five to eight. Fewer than five and the radar doesn't provide enough resolution to identify which specific area needs attention. More than eight and the scoring session takes too long and team members start choosing numbers arbitrarily. Six is the sweet spot for most teams.
1 to 5. A 10-point scale introduces false precision that doesn't exist in team satisfaction data. The difference between a 6 and a 7 on a 10-point scale is not meaningful. The difference between a 3 and a 4 on a 5-point scale (40% of the scale) is. Stick with 1–5 and treat the average as directional.
Investigate before assuming. A dropped score in 'collaboration' might reflect a difficult sprint with an external dependency, not a team culture problem. Ask: 'What happened in this dimension specifically that brought the score down from last sprint?' The change is the prompt; the answer is the insight.
No — it complements it. The radar provides quantitative measurement and trend data; the retro provides qualitative insight and action items. Run the radar first (10 minutes) to identify the low-scoring dimensions, then focus the retro discussion on those specific areas. The radar makes the retro more focused and efficient.
No exporting, no transcription. Snap the board, get the action plan.