The Sprint Retrospective: Reviewing the Scrum Process
The Sprint Retrospective vs The Sprint Review
The Sprint review focuses on the product or partial product itself. It is an opportunity to demonstrate the work that has been done during the sprint and provides stakeholders with the opportunity to examine the results and compare them with the expectations expressed in the sprint plan.
The Sprint retrospective, however, focuses on the process that has been followed to deliver the product. The Sprint retrospective is therefore an opportunity for the scrum team to take a timeout and reflect on how they adhered to the principles that define scrum, what worked well, and what needs more of their attention.
Sprint Review and Sprint Retrospective: Together a Team
Not that every project follows the same path. Not that the scrum process must be the same from project to project. Not that it must be the same from organization to organization and not that it must be the same from industry to industry. However, there is a general similarity from project to project, and this similarity reflects the way in which roles, artifacts, and events guide the process. So, the sprint retrospective gives the team a chance to reflect on how the process worked for them. How it worked in their circumstances and how it might be possible to improve the ways in which the team follows the scrum principles and process during the next sprint.
What do we look at during the Sprint Retrospective?
The opportunity to reflect on the process takes into consideration:
The people who worked on the sprint from product owners, to scrum masters and those on the project team
The relationships between the scrum team and all stakeholders, both internal and external
The processes including roles, events, and artifacts
The tools that were used
Preparation for the Sprint Retrospective
Preparation for the retrospective is a must.
Deciding who should attend
Working with the scrum team to create an agenda
Agreeing on the focus
Creating targeted questions
Setting a time to meet and setting time limits on the meeting
Who should attend the Sprint Retrospective
First, it goes without saying that the scrum master must attend. After all, this is the person responsible for ensuring that the team follows the basic principles and practices of scrum. this individual, however, must refrain from taking an authoritative role on any issue. Instead, the scrum master must remain in his or her role as a coach and advise, not decide. then, there is the product owner. Some might believe that this person's presence might make it difficult for team members to speak their minds. Regardless, most would agree that their presence is necessary. It might be appropriate for others to attend; however, this is up to the discretion of the team. In short, this is a meeting where the primary focus is on the team, not internal or external stakeholders.
What is the focus of the Sprint Retrospective?
The focus should be on the way in which artifacts were used, how they were useful, and how the team members worked together. It begins with the product backlog, moves to the Sprint review, the Sprint backlog, the process of execution, and then Sprint review.
Discussion should revolve around several issues during the Sprint Retrospective:
What worked well
What should the team continue doing
What did not work well
What should the team stop doing
How should the process be improved for the next sprint
It is also an opportunity to reconsider if the Sprint release at this stage reflects the initial product vision. Has the product owner or even the project team misunderstood what it was the customer really wanted? Have the stories failed to reflect customer needs? Is the definition of done inappropriate?
General Questions to Start Discussions During the Sprint Retrospective
Six questions can help provoke discussion:
In what ways was the sprint different from other sprints?
What worked?
What should be continued?
What didn't work?
What should be dropped?
What can be done to improve our approach to scrum?
Targeted Questions
General questions fail to focus on the real problems and opportunities. Here are some examples of targeted questions that may provoke a more detailed and substantive discussion:
Why do we sometimes fail to complete sprints within the time box?
Why do we find ourselves without the technical expertise necessary to solve our problems?
Do any of our problems keep reoccurring?
Do we need to improve our daily scrum to better engage our team members?
How can we improve engagement during the daily scrum?
How can we improve attendance at the Sprint review?
Does our team lack specific skills?
How Long Should the Sprint Retrospective Last?
Often, Sprint retrospectives are time boxed. Imposing this constraint helps keep contributions focused as well as limiting digressions from the main issues that need to be covered. this constraint can be especially difficult to enforce since these meetings should be self-directed. So, keep in the meeting on track is the responsibility of the entire group, although the scrum master may intervene if discussions do get out of hand. In general, a retrospective meeting may take longer than a Sprint review. Considering a sprint of 4 weeks, it would not be unreasonable for the Sprint retrospective to take 3 hours, for example.
Sprint Retrospective Cycle
It is not enough to generate a laundry list of problems. That is only the beginning. The group, needs to discuss this list and set a priorities on the actions that must be taken. sometimes, it may be necessary to take a vote followed by agreement that the group needs to commit to addressing one or more of these problems over the next sprint.
Sprint Retrospective Formats
There are several different Sprint Retrospective formats you can use, but I prefer the Lean Coffee method.