After each sprint review, a sprint retrospective must be started. A sprint review and a sprint retrospective tend to be misconceived by those who are just learning about agile. As shown in the table below, these two are different in terms of its purpose. A sprint review is a meeting to demonstrate the finished user stories during the sprint. The whole agile team is involved and anyone can provide feedback on what the team has completed; the focal point is the product itself. On the other hand, a retrospective does not only monitor the project’s progress but also the team’s interaction (Bennett & Bennett 2008, p. 161). It is a more critical part of the agile process wherein the team, the scrum master, and the product owner discusses what went right, what went wrong, and what needs to be changed in the previous work cycle.
A sprint retrospective focuses on collecting feedback to examine and to learn from the last sprint. The feedback must be from each member’s own point of view; otherwise, having the meeting would be pointless. A common technique to get feedback from each member is to set a couple minutes for the team to write on post-it notes what they think went well and things they want changed. Once a list of ideas is completed, everyone will vote on an item to concentrate on for the next sprint. By doing this, the crew can identify the biggest shortcoming and commit to fix it. Fitzgerald et al. (2013) found that this process mitigates risk since the group tackles the most significant risks first (p.871). In the next work cycle, time would not be wasted since the team will have a main task in mind as they continue to work on the project. Hence, an agile retrospective is the biggest factor for improving the performance of the team.
A sprint retrospective fulfills one of the twelve principles in which the Agile Manifesto is based on: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Regardless of how good an agile team is, there will always be a room for improvement. By looking back on the past completed tasks, the team is given time to reflect and find necessary enhancement. Having these constant individual reflections and group interactions is what makes agile effective.
Fitzgerald, B., Stol, K., O’Sullivan, R., & O’Brien, D. (2013). Scaling agile methods to regulated environments: An industry case study. ICSE ’13 Proceedings of the 2013 International Conference on Software Engineering, 863-72.