Running a Sprint Retrospective Successfully; Be The Perfect Sprint Master
There is always room for improvement, especially for a scrum team. A good scrum team should welcome and pay heed to any suggestions for further improvement. A sprint retrospective is conducted at the end of each sprint and you can think of it as a “lesson learnt” meeting.
The development team should set aside time to reflect on how they have been doing and then devise ways to make effective changes in the next iteration. The sprint retrospective is the perfect opportunity for the team to inspect and devise a plan for corrections to be enacted for the next sprint.
What Exactly Is Sprint Retrospective?
The Sprint retrospective is conducted prior to the next sprint planning and right after the sprint review. The retrospective allows the team to inspect “what worked this sprint and what could be improved in the next sprint”. Generally, a sprint retrospective requires a 3 hour period boxed meeting after each monthly sprint.
The event is shorter for smaller sprints. The scrum master is responsible for ensuring that all the attendants understand the purpose of the meeting and oversees the preparation for the event. The scrum master participates in the event as a peer team member and holds accountability over the scrum process.
The main function of the meeting is to:
- Scrutinize closely the progress of the last sprint, with regards to tools, processes, relationships, and people.
- Identify any potential improvements and appreciate the items that worked out.
- Devise a plan for incorporating improvements in the workings of the scrum team.
It is the duty of the scrum master to motivate the scrum team to progress, within its practices and development process and its scrum process framework and make suggestions to make it more enjoyable and effective for the next sprint. The scrum team sketches ways to boost product quality during each sprint retrospective, by adopting the principle of “Done” as appropriate.
The retrospective meeting is team centric, and thus each team member has a say in how the meetings would be conducted and how decisions can be implemented to enhance quality. By the end of the sprint retrospective, the team should have decided upon the rectifications that are to be made before the next sprint. Executing these enhancements in the subsequent Sprint is the duty of the sprint team.
WALKTHROUGH: How To Run A Sprint Retrospective Meeting
While there are various approaches to running a sprint retrospective, we’ll cover only two viable approaches in this chapter. Here’s how a scrum master runs a sprint retrospective meeting:
Approach 1:
Build The Product Backlog
The product backlog is simply a list of features that a product owner desires for the final product, and is built according to the business requirement. This list should be finished prior to the meeting, so that it can be presented to the team. These are the basic elements of a product backlog:
- The User Stories: Generally, each product backlog is necessarily a form of user story. A user story describes a product requirement according to the user’s perspective. The 3 R’s of every user story are; Role, Requirement, and Reason. This entails detailing the type of user that the requirement is focused on (Role), what the user is expected to do (Requirements), and why it is of value to the user (Reason).
- The Acceptance Criteria: The acceptance criteria can precisely demonstrate when that user story is considered done from the product owner’s point of view. Ideally, these tests should translate into acceptance tests which can be tested by a tester to verify their qualities.
Sprint Planning
Once the backlog has been completely cataloged, the question of “whether the team has everything it needs to realize the stories” arises. There are certain identifiable dependencies, such as contacts that need to be supplied, specification documents, and third-party feeds. The only way to be sure if a story is ready for the meeting is to ensure that the team members are aware of their goals and do everything in your hand to keep them focused.
Sprint Preparation
To keep the scrum time boxes running smoothly, background discussion is often important. For instance, the scrum master and the product master should ensure that user stories are completed before the meeting and the acceptance criteria are not vague. If possible, a preemptory meeting can be held between the tester, product owner, and the scrum master to review the proposed sprint backlog. Once the backlog is ready to be presented to the team, the meeting can proceed. According to the scrum guide, the goal of the sprint meeting is crafted from the selected items in the sprint backlog.
The Meeting
There are two halves to a sprint retrospective meeting. In the first half, the team decides “what” they aspire to do, and in the second half, the team decides “how” to get it done.
The “What Part”: In this part, the product owner reads out the features in the accepted sprint backlog. This exercise gives the team enough information about the sprint backlog. The team asks question to the product owner, to feel confident about the requirements of each product feature. Once the team is acquainted with the items of the sprint backlog, they can select a few items that they plan on completing before the next sprint.
The “How” Part: Once the team selects a handful of items, they can proceed to plan how they would go about delivering the sprint. The team accomplishes it through breaking each selected user story is to a subset of tasks. Once all the tasks are broken down, the team can finalize their commitment to deliver the sprint. The combination of these user stories and their subtasks constitute the sprint backlog.
Outcome Of Sprint Retrospective Meeting
After the sprint planning is completed, they team should be certain about what they are building, how they are going to build it, and complete their commitment of getting it delivered by the next sprint. In addition, the product owner should also be satisfied that the next sprint goals have been agreed upon.
Approach 2:
Set The Stage
The goal of the event should be introduced, and the agenda and format must be reviewed before commencing the meeting. You can either review the existing meeting norms or create new ones. If a specific topic requires separate focus and attention, identify the subject and ensure the compliance of all team members on this limited scope of key area.
The scrum master can get all the team members to talk through an introductory question, inviting every member to respond. The scrum master breaks the ice in the meeting to encourage collaboration and ensure more involvement by all.
Gather Data
The scrum master should identify the data that is going to be used, and needs to determine if it is readily available, accurate, and sufficient for the meeting. He should then proceed to present the project performance data gathered before the meeting, and an evaluation of the performance of the previously enacted improvement actions.
Some additional data may also need to be collected. Opinions should be shared and recorded via a directed exercise. Feelings and opinions are an indispensable consideration in evaluating and understanding project performance.
Generate Insights
All team members discuss and reach a common acceptance of the project performance, using the data that they have created and reviewed previously. Discussions should continue until a consensus view is achieved. Without this basis, the team would have difficulty proceeding.
Analyze the data; identify indicators of major predicaments, recognize shifting trends over time if you can garner access to historical data, emphasize any significant highlights, or presence of inconsistent and confusing information. Record your insights as these might pave way for proposed improvement actions and significant observations later. You can note them down on paper for a quick review.
Next, the scrum master needs to consolidate your insights. The collected insights are organized in to affinity groups, to prepare groups of related insights. Talk about each group separately, coming up unanimously with a name for each group and a common view of the key insight for each group.
Decide What To Do Now
Each group should be separately evaluated. A structured method can be employed to identify the importance of the highlighted problems. For immediate action, select only one improvement area and devote to completing this action using an agreed upon method.
The scrum master can choose this improvement action from the improvement backlog, or from the assessment of this presently concluded sprint. The “Improvement Backlog” is devised by the sprint team members, where they keep a list of things (Improvement Backlog Items — IBI’s) that are intended to improve the productivity of the team.
This action should ideally be addressed by the next sprint. For bigger actions, construct a series of smaller actions to be accomplished across a plethora of sprints. These also fall into the improvement backlog.
Close The Retrospective
The entire team goes over the identified improvement actions, top insights, and the collective view of the project performance, to provide opportunity for questions or clarifications in areas where agreement is lacking. A thriving retrospective generally concludes with agreement on these areas. The results of the retrospective meeting are saved.
The scrum master then proceeds to collect feedback on the outcomes of the retrospective. Each participant should be granted an opportunity to express their suggestions for the next meeting or vent out their degree of satisfaction over the results. These feedbacks can go a long way in strengthening the retrospective activities.
Tips To Ensure An Effective Sprint Retrospective
Create A Secure Space
A successful retrospective meeting comes down to safety and security. Until your employees feel safe enough to voice their frustrations, suggestions and concerns without fear of retribution, you can’t expect to run a successful sprint retrospective. Trouble ensues when problems are not addressed in a timely manner.
Effective leadership needs to be supportive of this by encouraging everyone to engage in meaningful conversation and open communication. In addition, you might want to exclude bossy managers, imposing executives, or anyone else whose presence might keep your team on their toes.
Nail Down Metrics To Track
If you want to earn an effective sprint retrospective, you need to take a data-backed approach to evaluate the success of your sprints. Before you start any project, be sure to identify the key metrics that will be used throughout the project to gauge your success at each successful sprint retrospective meeting. However, be open to altering these metrics, or even including new ones, as the project lays out.
Ideally, every sprint retrospective should include the reporting and evaluation of these metrics. This would also come in handy when you are planning for post-retrospective tasks. By prompting a brain-storming question such as, “What should we measure and analyze on the next meeting,” you will have a better idea of what to optimize next.
Create A Sense Of Responsibility
Most retrospective sprints revolve around teams complaining about what went wrong, or making pretexts about why it went wrong, without ever taking the blame for a failure. This is where you can set a tone. Start by owning up to the things you may have done wrong during the last sprint and encourage them to reflect on what they could have don’t differently. Instead of complaining and playing the blame game, your team would soon start to dive deeper into how they could have rectified the situation.
Start, Stop, And Continue
A great way to start a Sprint Retrospective is to ask each member what to continue, stop or start doing for the next sprints. For the “start” list, your team members can suggest what should be added to the scrum meeting, such as “everyone should arrive on time”, or we should start rotating the scrum master”.
The stop list includes all those items that your team thinks you should stop ding during the scrum meetings, for instance “stop taking more than 20 minutes for the daily standup.” Lastly, the continue list has all those items that the team is OK with becoming habitual.
Choose Your Scrum Master Wisely
Ideally, a scrum master should be impartial and empathetic, with the right skills to remain objective without taking sides, identify learning opportunities to get to the core of the issue troubling the team, act as an interpreter to make sure that everyone is on the page and every member understands what is being discussed, ask all the relevant questions to keep the discussion flowing smoothly, and summarize what has been agreed and what actions need to be taken.
Play A Game Of Expectations
If you want to keep everyone on the same page and engaged, you can play a game known as expectations. Give every member a sheet of paper, divided into two sections in the top half:
“What I expect from my teammates” and “what my teammates expect from me”. The bottom half of the paper is left blank. Each person has to fill in the top half for themselves and then pass the paper to the person on the left. Similarly, they receive the sheet from the person next to them, in which they fill in the lower half with what they actually expect from the person whose paper they are reviewing. After a full round, the team reviews and discusses expectations.
Try The Speedboat Retro
This exercise goes beyond the usual run-of-the-mill questions to help the team gain insight on things that are otherwise overlooked. Here’s a brief summary of the exercise:
- Island (vision): this is where you set long-term goals for the project.
- Wind (what helps you get there): you could get to your faster with better wind.
- Anchor (What could improve): Identify things that should not be repeated, things that went wrong and impediments holding the team back.
- The Rocks (Risks): Identify things that should be nipped in the bud before they become an issue.
