Retrospective meetings are bi-weekly huddle-ups of a team after every sprint. These are preferably done in person with the whole team at a set time.
Each member communicates answers to the following questions as clearly as possible.
This is in recognition on what has improved from the previous sprint or what generally went better spontaneously about the team in the current sprint. Take note that there must always be a reason why these improvements arise.
- "Our current velocity was faster than last sprint because team members helped out with blockers before the work day ends."
- "Coding was easier because of codebase cleanups that resulted to faster build times and easier reading."
This identifies issues or weakpoints that need to be addressed from the most recent sprint. Like the prior, there must always be a reason why these issues happen.
- "Turnout rate for bug fixes was slower because ticket details weren't elaborated properly or communicated well."
- "More bugs come up from every fix because of lack of test coverage."
Take note that even some things that might sound mundane could be valid, but easily addressed and fixed:
- "The aircon is too cold in the office and making me less productive"
- "There is too much noise during the peak times that I am in the zone"
Answers to this question address problems communicated from the prior question. The retrospective meeting must not end without a resolution to what can be better. Let's put into example some possible resolutions to the problems stated in the previous question.
- "Talk about the ticket with QA, Project Manager, Team Lead, or an expert in that area of code before starting to implement."
- "Be stricter in reviewing code that have areas that are not reached by tests."
- "Try to sit in the couch or the warmest area possible, or ask to turn down the AC temps during these specific times."
- "Code at the board room or wear headphones with ambient noise when you start to peak"
Be nice and do not point fingers. Remember that everybody is equally responsible for every sprint.
Do not be afraid to speak out on what can be better. It will not be held against you as long as it is sane and valid.
DO NOT end the retrospective meeting without resolutions to what can be better.
Commit on the part of "How to make it better", but also maintain and improve on "What went well".