Design Sprint retrospective

The retrospective is a collaborative critique of the team's design sprint. We usually hold retrospective meetings immediately after the sprint so everyone's thoughts are still fresh. Retrospective meetings do not have a specific agenda. The goal is to make sure everyone who participated in the sprint has a chance to provide feedback. The person who led the sprint will lead the conversation, and someone will take notes so the team can use the feedback to make the next sprint even more productive.

Retrospectives are very useful. They can help you work better as a team, improve communication with clients, and even point out areas where you can grow as an individual. Retrospectives are about empowering you, not shaming you. If something did not go well, this is your chance to make sure you have the resources and tools to do better next time. One of the most effective retrospectives I have attended was one where people actually felt comfortable and we focused on continuous improvement.

Common retrospective questions

The most important questions to ask during a retrospective are:

What went well?

What can be improved?

Answering these questions will help you work better as a team and as individuals. Make sure everyone feels empowered to share their experiences and that personal identifiers, such as race or gender, do not prevent members from being honest. Before the retrospective begins, tell the group that any feedback will be used to reflect on the experience and improve the process for the next sprint. Start the retrospective by discussing the parts of the design sprint that were successful and areas where the team did well. Perhaps a new process was created that could be applied to future sprints. Or maybe adding a new digital tool improved the team's productivity. Analyze your team's successes and consider how they can be applied to future sprints.

Questions you might ask in this part of the retrospective include:

What tools saved you the most time and effort?

When did you feel the most satisfaction?

What helped you contribute best to the team during this sprint?

This is also a good time to recognise a team member's strong performance. Celebrating success builds relationships and increases team cohesion and harmony!

After you have highlighted everything that went well, it's time to shift gears and think about areas that can be improved. Your team will want to know what went wrong so you can all do better next time.

Encourage everyone to join in the discussion about ways to improve. You could even take turns going around the circle and adding challenges to a shared list. If anyone is afraid to speak up, ask everyone to write their thoughts anonymously on individual sticky notes. Then all the improvements can be discussed together. This eliminates concerns about offending someone and reduces the risk of groupthink. Groupthink can occur in a group discussion when one person expresses an opinion and everyone immediately agrees with that opinion, rather than sharing their own feelings about an issue. Groupthink prevents each person from having an equal say, and it can mean that certain areas for improvement are overlooked.

Look at each stage of the design sprint to structure feedback: understand, ideate, decide, prototype, and test. At what point were there missteps? What caused those challenges? Share your perspective if one or two phases did not go according to plan.

Questions you might ask during this part of the retrospective include:

What went wrong that surprised you?

What problems occurred most often?

When do you think we had the biggest challenge as a team?

Then examine the outcome of the sprint or the final product, and ask questions like:

Did the team overestimate or underestimate the work required to complete the design?

Did an external factor derail productivity?

And, most importantly, does the final design actually solve the user problem?

Identify ways the team could have arrived at a better solution.

Remember, retrospectives are about empowering the team, not shaming them. This is not the time to berate an individual for poor performance. If you have issues with a team member's work, it's best to address it with that person privately, not during a team-wide retrospective.

At the end of the retrospective meeting, your team will have a better understanding of what went well and what could be improved. Of course, you'll want to take the lessons learned into your next design sprint.

Before the next sprint, review the conclusions you drew at the end of the last retrospective. You should take your conclusions into account when conducting the next sprint. You may need to involve a more diverse team, allow more time for ideation, or test with additional users before proceeding with a design.

Questions you might ask are:

What did you discover during the sprint that you are still wondering about?

How might the current process be preventing the team from developing better solutions?

Remember: voice your opinion and share your suggestions on how the next design sprint could be better. Do not be afraid to suggest anything you think will improve the project or the next sprint. The only bad suggestion is the one that does not get shared!