.svg)
A retrospective is defined as the “looking back on or dealing with past events or situations.”
It’s a reflection of sorts.
And in the case of a sprint retrospective, it’s the reflection of past sprint events — a meeting between various members of the engineering team and stakeholders in the organization. Everyone has a chance to speak — and every voice is valued.
So, what is the purpose of the sprint retrospective meeting? Who attends this meeting? And how often does it happen?
Within the Agile framework, there are what you call the five ceremonies of a sprint cycle. The agile sprint retrospective is one of these events, and it tends to occur at the end of one sprint and going into the next.
Here, everyone gets a chance to talk about their experiences as they progress through the software delivery lifecycle (SDLC). They’ll discuss observations from sprint to sprint and have the opportunity to defend their actions along the way.
Everyone who attends daily scrum sessions will likely find a presence. Sprint retrospectives give everyone a chance to air out their struggles as they work together in unison to fix them.
Sprint retrospective is specifically designed to improve engineering productivity. The goal of the meeting is to reflect on the previous sprint and identify areas for improvement. This helps to increase engineering productivity and improve the quality of the product being developed.
There are five different ceremonies to every sprint cycle. Each ceremony marks a pivotal moment during the software lifecycle and just as important as the next to keep development teams on target.
During each event, there will be some sort of discussion detailing the various phases of development, what needs to be done, what has been done and what can be done differently.
The sprint cycle and ceremonies are included below:
When it comes to having a conversation about sprint retrospective meetings, other distinct ceremonies also seem to come up. The sprint review is one of them, the standup is another. Knowing the difference between all three events is important because they each play a vital role in successfully managing the software development lifecycle.
During a sprint review, development teams usually meet to talk about the product and product development, accomplishments and any progress made since the last sprint meeting. So, it’s not rare to see product demos from time to time.
Regular sprint reviews help developers better meet the needs of their customers and provide a better customer experience. They’re held at the end of each sprint and are essential when planning for the next.
A sprint retrospective, however, has been designed to help teams exceed customer expectations while strengthening the workforce and improving the performance of everyone in it.
Retrospectives push teams to become faster, smarter and happier. The entire team — the developers, the scrum master and even the product owner — come together to look back on the “just completed” sprint and find ways they can improve before moving on to the next.
Sprint reviews allow leadership to highlight the hard work of the entire development team, single out individual contributions and celebrate collaboration. It’s a technical event, whereas retrospectives are designed to focus on improvements — whether improvements to process or as a team on the road to engineering excellence.
A scrum session — or a sprint standup — is a daily meeting that lasts only about 15 minutes. Here, teams discuss the progress of each project and any backlog that needs to be addressed. They’ll quickly note any issues they’ve encountered and the steps taken to find a resolution.
Standups are like a minified hybrid of the sprint review and retrospectives. While they do cite historical events, the focus is more on moving forward, keeping everyone on the same page and serving reminders that help keep track of progress.
After the sprint review, scrum team leaders often meet to discuss how well the most recent sprints were completed, determining quality, output and effectiveness. Scrum masters guide, coach and make sure the team stays focused. They’re encouraged to learn from past mistakes, streamline workflow activities and improve processes over time.
The overarching goal of every sprint retrospective is to make scrum teams better, improve technical processes and increase the quality of production while developing a culture of productivity.
These sprints give everyone a chance to take a deeper look at problems they’ve encountered and to turn them into positive teaching experiences. Not only do they get to look back at what went wrong, but they can also discuss ways to prevent it in the future.
Each session should increase the quality and effectiveness of teamwork and collaboration, individual contributions and processes carried out during each iteration.
The scrum master will most likely take charge of the sprint retrospective. However, product owners may also join in to not only add their own opinions, but to also gather valuable feedback and information regarding the development process and journey to date.
The scrum master will break down how teams are performing and what they can do to become better. As a team, the scrum master will most likely discuss ways to improve their communication and become stronger through collaboration. He or she will address individual contributions, relationships that have been built, as well as those that have been broken.
The scrum team will communicate which processes have been carried out and which will continue through the next sprint. They’ll also have the floor to address ways they believe they can improve as a team and how they’ve already improved since the last session.
Gaps will be highlighted. Bottlenecks will be uncovered. New tools will be discussed. And missed opportunities, pointed out.
This is a moment where the team gets to reflect on how they can become more effective, how they can become more efficient and how they can drive more impact. It’s all about improving as a team and growing as a unit.
After all, what is the purpose of the sprint to begin with?
The scrum team should always be looking for ways to increase the quality, output and effectiveness of their work. But sprint sessions, particularly sprint reviews and sprint retrospectives, give them an excuse to prioritize it over time.
It’s an excellent way for the entire team to reflect on industry best practices compared to their own habits. They can exchange ideas on what works and what doesn’t while constructively critiquing each other’s work in the process.
For the most part, they will discuss what went well in the previous sprint or sprints, what could be improved in future sprints and what needs to be improved by the next sprint, regardless of production.
“Sprint retrospectives can help your team avoid some common pitfalls, such as operating in silos or misalignment on scrum processes and goals. It’s all about working together as a team to reinforce agile principles, improve practices and surface any roadblocks on a regular basis,“ explains Lauren Moon, a Writer at Trello.
While sprints will often vary in size and length, most sprint retrospectives follow the same type of itinerary and are often encouraged by leaders within the enterprise space. When conducting an agile sprint retrospective meeting:
Create a punchbowl for suggested improvements.
Review the facts and set a positive tone for what will be discussed. Start off each session by asking for suggestions. Get creative for those who’d like to remain anonymous. Make sure to take notes and take this feedback into consideration. Have them share their experiences, then add your own suggestions. Don’t be afraid to ask teams to try adopting new habits. Experimentation should be rewarded and could lead to new revelations over time.
Establish a culture of honesty, openness and transparency.
Make each participant feel comfortable when speaking. Empower them to not only say what’s on their mind but to ask questions and speak on the things that are bothering them.
Make sure your team feels heard.
Allow each and every one of them to have a voice. Let them know that their opinions are valued and that you’re genuinely concerned about the things they care about most. Allow them to defend their stance on “controversial moments” and allow them to provide clarity from their point of view. Let your team know that it’s okay to celebrate failure and that, ultimately, it’s what helps the team grow.
Understand that every member of the team is actually an ambassador.
Day in and day out, they’re the ones in the trenches. They provide critical feedback and data that provides leadership with a window to understand what has happened throughout the process of development and what they can expect from the team going forward.
Avoid postponing or putting off an event.
Shared experiences are essential to collaboration and are critical to moving forward as a unit, synchronizing on all fronts and improving all performance. Make sure each event is action-oriented and that insight is made actionable. Keep it fresh, keep it engaging. Bring in an outside perspective when and where possible to give a differentiating opinion.
Avoid bringing up or coordinating the backlog if possible.
Sure, there are times when the backlog will need to be brought up. But given the backlog's technical nature, it should instead be discussed during the sprint review meeting. In addition, backlog can build unnecessary pressure when you should be building a presence of motivation — talking out hardships and walking away feeling refreshed.
Gather data from previous sprint retrospectives.
Use this as a guideline when discussing what’s next. Layout where the team has improved and where they still can do better. Ask each and every member to give their own perspective. Don’t forget to generate data from this meeting because it will also be used in the next.
Don't be afraid to ask questions.
Because if you don’t, you’ll never know what you’ll never know. Show gratitude for the answers. Sometimes the smallest detail has the greatest impact. And all insight provides foresight, especially when looking back at mistakes in hindsight.
Summarize the sprint retrospective.
Reiterate lessons learned and share your own takeaways from this event. Ask everyone for their input, feedback and advice. Allow this to become an opportunity to learn. Gather information, especially in areas you may have otherwise missed.
Maintain a log with notes on each session.
Remember who said what when, and follow up when necessary.
The length of a sprint retrospective meeting is generally no longer than three hours in relation to a one-month sprint. Shorter sprints often mean shorter scrum retrospective events. But, this number can vary based on how many team members there are, the agenda and the points to be addressed. It’s also based on whether the team is present on-site or if remote teams are included. It also depends on whether team members actually need to be brought up to speed, to begin with.
The communications team at Adobe provides this rule of thumb:
“Encourage your team to try different sets of activities during the meetings, or dig deeper into follow-up tasks with a unique approach tailored to their personal needs,“ recommends Moon.
Zoho suggests asking teams the following questions:
According to Scrum.org, during each sprint retrospective, the scrum team should plan ways to increase product quality by improving work processes and adapting their own definition of “done.” The sprint retrospective should always provide development teams with a formal opportunity to focus on “inspection and adaptation” in a friendly yet open and honest environment.
Adding to this concept, Atlassian also suggests mapping out at least two months' worth of sprints and asking team members, specifically, to call out what stood out at each of these events, noting that it’s a good way to refresh everyone’s memory, set the stage for each new session and act as a motivator in the case of a job “well done.” It’s standard project management.
The next step would be implementation. Encourage the team to take action. Keep a log of actionable goals and to-do lists for the team to accomplish. This can be done electronically or in a physical sense. Some teams use platforms like Jira, while others prefer traditional Kanban as long as it serves the purpose of reminding the team when they’re not “done” or in progress.
From here, the retrospective is only half done. It’s up to the team to keep up with improvements.
With a platform like Jira, scrum masters can easily add goals, assign existing issues and validate whether each goal has been met or attempted. As a result, they’ll know how many tasks require more time to complete while prioritizing those requiring a little more effort.
Because it’s basically a digital “to-do” list, scrum teams will be able to visualize the backlog of sprint goals and embrace the overall big picture as a vision for the future. It’s more than just allowing them to mark goals “in progress” or “done.” It’s also about inspiring with how many tasks they’ve been able to complete.
Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
.svg){kind=small}
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.
.png)
