Agile Retrospective

Four questions to review your last sprint and plan changes.

Try this retrospective live

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?

What is an agile retrospective?

An agile retrospective asks four plain questions: what went well, what went less well, what you want to try next, and what still puzzles you. Together they get your team talking about how the last sprint went and which actions to focus on in the next one. The format is simple on purpose. Running it tells your team you're listening and that you intend to act on what they say. The retrospective practice itself is described in Agile Retrospectives, the book by Esther Derby and Diana Larsen (with a foreword by Ken Schwaber), and it works like a regular tune-up that keeps your team running well. Held every sprint, the retro surfaces problems in how you build and ship software while they're still small, and gives your team a set time to fix them together. Short, regular retros with documented actions let you change course before it's too late. Steering a big ship works the same way: small corrections along the route are easier than finding out at the end that you've docked in the wrong port. A post-mortem looks back once a project is over. An agile retrospective looks ahead to the next sprint, so the tone stays positive and practical.

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 your team wants to pin down specific things to improve.
  • After a major project milestone or release to discuss lessons learned.
  • Whenever your team feels stuck and needs to get back on track.
  • During an agile transformation, to make regular reflection a habit for every team.

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?

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Set a blame-free tone at the start so people speak openly.
  • Timebox each section so the retro stays focused.
  • Get input from everyone, not only the vocal few. A few minutes of silent brainstorming helps.
  • Capture action items and give each one an owner who follows up.
  • Don't try to solve every issue. Pick the top one or two and run small experiments.
  • Rotate the facilitator role so you get fresh perspectives.

Frequently asked questions

What is an agile retrospective?
An agile retrospective is a meeting at the end of a sprint where your team looks at how the work went and agrees what to change. This template uses four prompts: what went well, what went less well, what to try next and what puzzles us.
How often should you run an agile retrospective?
Most teams run one at the end of every sprint. You can also run one after a major release or milestone, or whenever the team feels stuck.
How long does an agile retrospective take?
The Scrum Guide caps the sprint retrospective at three hours for a one-month sprint, and shorter sprints get shorter retros. For a two-week sprint, 45–90 minutes is common.
What's the difference between an agile retrospective and a post-mortem?
A post-mortem happens once, after a project ends, and looks back at what went wrong. An agile retrospective runs every sprint, so your team can fix small problems while there's still time to act.
Can remote teams run an agile retrospective?
Yes. In TeamRetro, distributed teams add ideas, group them, vote and agree on actions together in real time from anywhere.

Related templates

Four Ls Retrospective

Reflect on what your team Liked, Learned, Lacked and Longed for

What? So What? Now What? Retrospective

Go from what happened to what you'll do next.

Start Stop Retrospective

Two questions: what to start, and what to stop

Drop Add Keep Improve Retrospective

Decide what to drop, add, keep and improve.

Ready to run this retrospective?Try this retrospective live