During the agile retrospective, also known as retro, the team reflects on what happened in the iteration and identify actions to focus on the continuous improvement.
In those meetings, identified as one of the ceremonies of Scrum framework, and timeboxed to three hours or less, the team reflects about the daily work of the team itself, both qualitative and quantitative way, endeavoring to uncover what is working well, what isn’t, and what can the team do better the next time.
The quantitative side of the agile retrospective is relatively easy to address and understand, provided that we have access to data about work and team performance. Metrics about team velocity, value delivered, defects density or even data about team’ happiness are really relevant in every day life of a good agile teams, and may provide clues to proposing improvement actions. Having a history of all the data that as a team we consider relevant we can do comparisons and identify trends and breaking points that have affected productivity, and we will obtain conclusions about what has been happening in the team over the time.
Thus, the quantitative side of an Agile retrospective seems a simple task, but it is not the case of the qualitative side…