Sprint retrospectives are a technique in Scrum, used primarily to reveal or disclose the shortcomings and behavior of the scrum team to itself. When it becomes possible for a self-organizing body or a system to correctly identify the pitfalls and problems faced by it, it is possible to correct them by implementing proper solutions which can eradicate the impediments and remove the problematic issues from its roots. During scrum implementation, sprint retrospectives help to identify any erroneous working or problems faced by the team, and efforts are made to correct the problems in time. For retrospectives to be meaningful and useful, more emphasis should be stressed upon self-reflection – each member of the team should feel personally involved and responsible for the outcomes derived out of the sprint activity. This is one of the main essences of scrum. In addition to collaboration and team effort, scrum framework strongly promotes self-analysis and self-correction. Sprint retrospectives help to incorporate these scrum features during the implementation stage.
Features of a healthy and beneficial sprint retrospective
The scrum guide has little to say about what an ideal retrospective should consist of. Since scrum is all about adapting to changes and collaboration of activities, it can be very difficult to specify exactly what the retrospective should include. Business processes can vary, and scrum implementation may be carried out in a customized manner to suit the particular organization or business. In short, it may be very difficult to define and standardize a retrospective. Rather, it would prove to be more meaningful and effective if the objectives and results of the retrospective are to be considered, instead of its anatomy or structure. Teams may vary, and can be big or small in size. The location should be ideally fixed, but it too can change as per convenience and feasibility. What does not change are the objective for which the retrospective is to be held, and what results are to be obtained out of it. Ideally, a sprint retrospective should support the following features:
- Each team member should engage in the discussion and actively support it in a pro-active manner.
- Discussions carried out ought to focus upon team activity and teamwork rather than individual team members.
- The definition of “Done” is clearly defined and explained properly to team members. Completed user stories should be accepted as “Over” or “Complete” only on the basis of the definition of “Done”.
- A list of all actionable commitments should be created.
- The results of prior retrospectives are thought about and analyzed from time to time.
- Only relevant discussion pertaining to scrum implementation should be carried out.
Who attends the sprint retrospective?
Everybody associated with the scrum project and scrum implementation should attend the retrospective. This includes the product owner and all team members. The scrum master too attends the meeting, but rather than indulging in active discussion, he or she engages in a manner which can facilitate the meeting, and positive results are derived out of it.
Supporting the correct spirit while holding the retrospective
Regardless about who attends the meeting, or the level of seniority, there should be active participation by all the attendees, and discussions should be carried out in an open manner with a clear view of finding true and genuine solutions, rather than finding faults of individuals. Of course, self-introspection and error finding is a must as far as scrum is concerned, but instead of targeting specific individuals, it is important to discuss about team as a whole, and find solutions collectively.
“Please visit http://www.quickscrum.com to download the Quickscrum tool”
