What went well?

Things we are happy about.

We delivered all committed stories and met the sprint goal.
Our daily standups were efficient and helped us stay coordinated.
The new pair programming approach improved code quality.
What went less well?

Things we should improve.

We struggled with unclear requirements and had to make assumptions.
Testing was rushed at the end due to scope creep earlier in the sprint.
Communication gaps between frontend and backend teams caused delays.
What do we want to try next?

Things we should do differently.

Bring a subject matter expert into planning and grooming meetings.
Do a design spike for complex features before implementation.
Timebox tasks to avoid getting stuck in the weeds.
What puzzles us?

Unanswered questions we have.

How can we improve our DevOps practices and deployment process?
What skills do we need to develop as a team for the upcoming project?
Should we look into new testing frameworks or tools?

Continuous Improvement Through Agile Retrospectives

The agile retrospective technique asks 4 basic questions that gets the team thinking about the outcomes of the last sprint, and what actions they should focus on next. While it is straightforward, it sends the basic message that you are listening and geared for improvement. Based on the book by Esther Derby, Diana Larsen and Ken Schwaber, this tried and true method acts as an engine tune-up that keeps your team working at peak performance. Held regularly, it uncovers issues with the software development life cycle and gives your team a way to solve it together. Rather than running a post mortem, regular agile retrospectives that are short, sharp and documented means that you can quickly make changes before it’s too late. Much like steering a big ship, it’s a lot easier to make small changes en route to the destination, than finding out at the end you have docked in the wrong port. Unlike debriefs or post mortems is it is intended to have a more positive and proactive focus.

Agile Retrospective Format

What went well?

Things we are happy about.

Encourage the team to share specific examples of successes, big or small. Celebrate team accomplishments and individual contributions.

What went less well?

Things we should improve.

Create a blame-free environment for open and honest discussion. Focus on processes, not individuals. Look for root causes.

What do we want to try next?

Things we should do differently.

Encourage creative thinking and be open to unconventional ideas. Look for small, practical experiments to run in the next sprint.

What puzzles us?

Unanswered questions we have.

This is a chance to surface unknowns or areas needing further investigation. Capture these for future discussion.

When to use this retrospective

  • At the end of each sprint or iteration to reflect on the past cycle.
  • When a team wants to identify specific areas for improvement.
  • After a major project milestone or release to discuss lessons learned.
  • Whenever a team feels stuck and needs to get back on track.
  • As part of an organization's agile transformation to foster a culture of continuous improvement.

Suggested icebreaker questions

  • If you could add one tool or process to help our team, what would it be?
  • What's one small thing that could have a big positive impact on our team?

Ideas and tips for your retrospective meeting

  • Set a positive tone and create a blame-free environment for open discussion.
  • Timebox each section to keep the retrospective focused and productive.
  • Encourage participation from all team members, not just the vocal few.
  • Capture action items and make someone accountable for following up.
  • Don't try to solve every issue - prioritize and experiment incrementally.
  • Consider having a rotating facilitator role to get fresh perspectives.

New to retrospectives? Read our guide on how to run a retrospective →