Blogs

Sprint retrospective meeting is considered one of the most indispensable meetings in Scrum. Among all Scrum meetings, Retrospective definitely is of the most difficult. In many teams, Retrospective meeting is usually skipped because facilitating the meeting is not easy.

Sprint retrospective meeting is the last event in a sprint held by Scrum team to look back at what it has done during the last sprint. By doing this, the team is practicing the Agile “inspect and adapt” principle.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is considered one of the most indispensable meetings in Scrum. Let’s take a look at the core of a retrospective meeting:

  1. Engaging the team, optionally with some guests
  2. Focusing on the team performance rather than individuals.
  3. Revisiting the Definition of Done and result of previous meeting.
  4. Creating a list of actionable commitments.
  5. Building a respected and safe environment to raise voice.

To facilitate the meeting is not easy. Among all Scrum meetings, Retrospective definitely is of the most difficult. In many teams, Retrospective meeting is usually skipped because of following reasons:

1. When a Sprint fails, a bad Scrum Master will ask the team to find out the responsible person and pressure the person on his failure. This is extremely bad because not only it does not solve anything, it also shatters the team spirit and disunites the team into individual’s responsibility; QA blames Dev, Dev blames Db etc…

2. The discussion if is not well directed can be never-ending and easily create a tense or boring team environment. An example can be a member keep finding excuses for failing some user stories while another one instantly proves those excuses invalid.

3. After the retrospective, we need a list of actionable commitments. The commitment must be in S.M.A.R.T model. For example: “From next sprint, the team will fix bugs more carefully” is absolutely not an actionable commitment. A good example would be: “Before fixing a bug, we will write a unit test to prove that bug exists”. This is very easy to answer Yes/No when we review the back log.

4. Because of the above reasons, the retrospective creates nothing valuable but fears and boredom to the team, which will only make the situation from bad to worse.

If you find your team in the list, there is chance that you are doing themeeting the wrong way. To fix this, we need to get back to the core values of doing retrospective and make sure that the meeting matches them.

By Hiep Le