Retrospective

What is a retrospective?

Definition: A retrospective, sometimes called an agile retrospective, is a meeting that is held after a product has shipped. The goal of the meeting is to discuss what happened during the product’s development cycle and release process. By reflecting on what went well, and what could have gone better, the team can take these learnings into the next development cycle, thereby continuously improving not just the ways of working but the quality of output too.

What is a retrospective used for?

To quote Steve Jobs: “Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.”

This goes some way to explaining why retrospective meetings are so important. Even the best product teams are not immune to mistakes, be that oversights, disorganization, misunderstandings, or any other product development ‘failures’. 

Thing is, it’s okay to make mistakes — what’s important is that you learn from them. Otherwise, you’re likely to encounter the same issues again in the future and that can have big consequences. After all, it’s not just your team who is impacted by errors, but your end-users too.

That’s why an agile retrospective is used to bring a product’s development team together, to reflect on the development process, discuss what did and didn’t work, and make commitments for how to improve in the future.

Although in an agile environment the core focus may be to get a product out of the door and to the customer in as short a time as possible, that doesn’t mean teams shouldn’t loop back in the end and have a look at what has been done.

What a good retrospective meeting looks like

The success of a retrospective depends entirely on how the meeting is conducted and the format it takes. This is because the whole value of a retrospective comes from the group conversation and dialogue; it is not simply a case of calling everybody together and dictating the contents of a PowerPoint presentation. 

So, what should a retrospective look like?

In product development, there are two important loops. One loop produces the shippable product. The other examines how the project was handled and how people worked, both the good and the bad, so that improvements can be devised and pulled into the next production loop. This helps teams to improve over time and deliver consistently better products. 

eBook

How To Use Customer Feedback for Business Growth

Read now

A retrospective meeting should bring together all teams and team members involved in both of these loops. At this meeting, at least one representative from each group should be given time to share their view of the overall development experience. 

The more people that you can fit in to speak with, the better. 

The best retrospective meetings give every single person involved in a project some floor time to speak their mind, say how they felt, and offer ideas for how they think it could go better next time. Examples of teams and individuals who may be involved in a retrospective meeting include marketing, sales, product design, customer experience, and operations. 

How should a retrospective be conducted?

There is no set structure, formula, or list of rules that govern retrospective meetings; organizations are free to conduct them as they see fit. Some organizations prefer to sit down and just allow people to speak, whereas others take a more interactive approach, incorporating mindmaps, anonymous feedback activities, and visual aids. 

More often than not, retrospectives are led by employees from the product management team. These people often perform the most cross-functional roles in the organization and therefore have a broader and more generalized view of what happened during a project. In contrast, sales teams, for example, have a much narrower view that doesn’t account for much that happened outside of the sales ‘bubble’.

Even though there are no set formats or ‘rules’, deciding on your organization’s own format for these meetings is key. For a retrospective meeting to be effective, it needs to be conducted in a way that promotes conversation and dialogue — very little value can be drawn if only a few people in the room are speaking up, or a lot of people are saying a lot of things, with no-one capturing what’s been shared.

Managers and other higher-ups should also remember that the meeting is a fair ‘safe space’ for bringing up issues and topics that may go against their own views. To that end, higher-ups should avoid the urge to be contentious and dismissive. 

In any retrospective meeting, it is a good idea to bring in an impartial third party that was not involved in the project being discussed. This person can act as a sort-of referee to ensure everybody at the meeting is treated fairly and given a chance to take the floor. 

Lastly, although the retrospective provides a platform for honest feedback, it shouldn’t focus only on the negatives. Far from it! Retrospectives are also an ideal time to celebrate wins and praise team members for a job well done.

What should a retrospective’s end result be? 

Just like there is no set structure or ‘rules’ for the meeting, there are no right or wrong outcomes either. At a minimum, however, every retrospective meeting should result in some form of list or bank of information of things that went well, things that could be improved, and anything that went quite badly wrong. 

These lists can be long and exhaustive or short and sweet, as long as insights have been gathered, then the meeting can be called a success. 

In addition to listing these things out, the discussion should explore why they occurred. The goal here is to understand how positive and negative occurrences unfolded so that future projects can replicate good elements of a project’s process and avoid the bad ones. 

Overall, participants should come away from the meeting with a deeper understanding of how the project went, how others felt about it, and how they can positively change their method of working in the future.

What is a sprint retrospective?

With more and more teams embracing agile ways of working, sprint retrospectives are big on the agenda. But what is a sprint retrospective and how do you run one?

Sprint retrospectives are a way to look back on the work performed during a sprint, with the intention of improving both individual and team processes. As the name suggests, sprint retrospectives are performed at the end of every sprint and the objective is to answer the following questions:

• What worked well in the sprint?

• What didn’t work well and could be improved?

• What will we commit to doing differently in the next sprint?

Sprint retrospectives can help teams to make the most of the iterative nature of Agile development. With every sprint, the team learns new ways to work and add value to the project. By taking time to reflect and plan for growth, teams can unlock the full potential that agile methodologies hold.

Continuous improvement can only happen when someone reflects on previous work and can assess it without the pressure of deadlines or sprint length. Sprint retrospectives are also an opportunity to reinforce the team’s ownership of the project, helping to build a sense of pride in their work. By allowing the team to be involved in evaluating the progress, they are more likely to support any changes that are contained in the next iteration.

Who should be involved in a sprint retrospective?

As the sprint retrospective is a time to reflect upon the project’s process, the entire team needs to attend the meeting. This includes the development team, the product owner, and the scrum master. 

While it is permitted, it’s not recommended to invite stakeholders to retrospective meetings. The discussion will rarely involve topics that are relevant to them. 

What is a sprint review?

For newcomers to Agile, sprint retrospectives and sprint reviews may seem like the same thing. But the two events serve specific and different purposes. Now that we’ve covered what a sprint retrospective is, what is a sprint review? 

Sprint reviews are designed to help the team look at the current state of the product from a customer’s perspective. This helps reinforce the needs of the customer and the importance of maximizing value to them. The sprint review is also an opportunity to update stakeholders on the project’s process. 

The sprint review is broken down into three steps:

• Demonstration

• Discussion

• Product backlog update 

Step one tasks the team with presenting what work was completed during the sprint. As the nature of scrum dictates that the team can only present completed products or increments, the development team can demonstrate features to the stakeholders for evaluation. 

Step two opens the floor to a discussion between the development team and stakeholders. This discussion should serve to bring stakeholders up to date with the project progress, provide added business context to the developers, and motivate the development team by reinforcing why they are building the product. 

Finally, once the sprint review is completed, the product backlog is groomed based on what has been discussed during the meeting. This helps ensure that the product backlog, development team, and stakeholders are all aligned with the product goals.

So now you know what a sprint retrospective is and what a retrospective review is, you can get started.