End-of-Year Retrospective Model

End-of-Year Retrospective Model

How to Conduct an End of Year Retrospective Session

Conducting an end-of-the-year retrospective session as a scrum master for developer teams or companies that are fully agile, is an important decision to make as the year goes to an end. If you are a fully agile team then, during the year, you should have conducted a minimum of over 20 retrospective sessions. As a scrum master, the end-of-the-year retrospectives model allows you to review the entire year with your developer teams by looking at some key indicating factors which I categorize into the following headings:

  1. Achievement

  2. Failures

  3. Stopped Doing

    The scrum master should prepare the end-of-year retrospective board by using any of his favorite end-of-year retrospective templates then carefully go over the board for the past year and group all the feedback, action points, decision points or pain points as suggested or agreed by the team during each retrospective session throughout the year into the above categories.

    Achievement

    The achievement category can further be divided into two or sub-categories such as:

    1. Tech/ Tools /Project: here you are to put all achievements in your teams that fall under technology, tools or project related, for example, your team migration from an old database to a new one, your product got her 1st major paying customer etc.

    2. Process / People / Others: here you should group all achievements in your teams that fall under process improvement, people management improvement or achievement into this section for example we hired two new DevOps engineers, holding regular teams daily meetings or standup sessions, timely fixing of all bugs in the backlog sheet etc.

      Failures

      During the year in review, if some things were agreed upon during the retrospective session but couldn't be done until the year ended such items can be grouped here such as the inability to hire a 2nd Java developer, not being able to pay for developers who planned to take the AWS training, not meeting up with agreed metrics for your product etc.

      Stopped Doing

      They stopped doing sections that should cover great things that the team was previously doing but somehow, these things were dropped or forgotten during the year for example creating a very small pull request, and finishing up sprints within the 2 weeks agreed on a schedule.

      During the end-of-the-year retrospective session, the scrum master or product manager should discuss all the above with the agile team, take feedback from the team and lastly discuss the direction or what the team should look forward to in the new year.