Reflecting on Results (Sprint Retrospective)
During the sprint retrospective, the teams reflect on their processes and evaluate the way that they work. This introspection occurs at the end of the sprint so that the team can implement any improvements in the next sprint.
Who Attends the Retrospective?
All members of the development team, the scrum master, and the product owner attend the retrospective.
When Does the Retrospective Occur?
The retrospective occurs on the last day of the sprint just after the sprint review.
What Happens During the Retrospective?
The team evaluates the sprint and looks for what went right (that should be continued) and for what went wrong (that needs to be corrected). The team strives to find ways to become more efficient and to work better together.
Anything relating to the sprint is fair game for discussion during the retrospective.
- Were items properly groomed before being pulled into the sprint?
- Were requirements clearly defined and acceptance criteria written based on those requirements?
- Are team members engaged and listening to each other during daily standups, or are they prioritizing other work over communicating with the team?
Retrospective Takeaways - Stop, Start, Continue
One way to capture information during the retrospective is to define what processes the team should stop, start, and continue.
The team should stop any processes that are negatively affecting the team, such as not grooming backlog items appropriately. Improperly groomed items may result in stories that are too large to be completed in the sprint or may result in stories that do not have adequate acceptance criteria defined, resulting in work that cannot be accepted by the product owner.
The team should start processes that can help them communicate or perform at a higher level. This can be something as simple as making sure that teammates start listening to each other during daily standups rather than holding sideline conversations, or it can be starting to defend their story point estimations, even if one person has a different estimation than the rest of the team.
The team should continue any process that is currently working well, whether it was something new implemented in the current sprint or something that they have been doing for some time.
You can go around the room during the retrospective and give each team member the chance to define any process they would like to start, stop, or continue. This information can be captured and placed where each team member has easy access. The following table show some items that one team has agreed to start, stop, and continue:
| Start | Stop | Continue |
|---|---|---|
| Request for design reviews before starting work on a task. | Delaying code reviews and holding up an entire sprint cycle. | Coming together to help when a task is stuck. |
| Review action items from prior retros that we are following. | Stop giving in on your story point estimation and defending your choice. | Being thorough and not compromising on code reviews. |
| Everyone to start contributing to group discussions. | Meetings without agendas | Checking in on task progress on Wednesdays. |
| Give context and intro before starting demos. | Rushing to commit changes | Minimizing context switching. |