Get certified - Transform your world of work today


Do's and Don'ts of Agile Retrospectives

Tips for healthier retrospectives

28 July 2014

Hesham Amin

One of the core Agile practices is to inspect and adapt. We inspect the developed software in the business review or demo meeting to ensure that we are delivering the right product. And we inspect how the team performs and interacts in the retrospective meeting to make sure that we are working in the right way and that we keep improving.

We should work on maximizing the benefits of the retrospective meeting and adapt according to its outputs, or it will turn into a useless ritual.

In this article, I share some tips on things you can do to improve your retrospective meetings, and things you should avoid as well.


  • Make the retrospective a safe place to express issues. Team members should not feel worried about expressing their opinions on things that need to be improved. They should be totally comfortable to speak.
  • Ask, "What else?" instead of, "Anything else?" You know, these small things matter. Deliver the message that team members are welcome to contribute instead of a message that says, "Enough wasting time, I'm bored already."
  • Motivate the team to participate. In a team new to Agile, we played a game to encourage all members to participate. Each member in his turn named a point to improve, introduce, or stop doing -- or he could use his pass card (each member had a "pass" card that he was allowed to use once). The winner was the last one to use the pass card, the one with the most ideas. Revise the game as needed, according to team conditions.
  • Give a hand to introverts and shy people. You know that guy who prefers "Pull to refresh" on his mobile Twitter app to engaging with what's happening around him in the meeting. We need to listen to him too. He has a lot in his mind regarding how things are going -- or should be going. Don't pull him suddenly out of his safe corner by asking him directly to participate. Give him safety and a hidden invitation to speak by saying something like, "We've not heard anything yet from the group in the corner." This is better than focusing the spotlight on him directly.
  • Change the structure of the three common questions. Especially in teams with high negative energy, I prefer to structure the meeting in terms of: What to introduce, what to keep doing, and what to stop doing (instead of: What went right, what went wrong, and what to improve). Although I personally believe that the second, standard format makes more sense, teams sensitive to self-criticism might prefer the first.
  • Plan the retrospective. After the team breaks the ice, gains trust, and becomes confident that opinions and ideas mentioned in the retrospective are valuable and make real changes, you can change the retrospective to another format. Instead of having a brainstorming-style retrospective, the ScrumMaster can gather feedback from the team during the iterations, and agree with the team in advance about the agenda of the retrospective, in order to focus on deep discussion and problem solving during that meeting.
  • Make it fun! This is always best, especially if team morale is low or the team is new to Agile and used to feedback meetings where the manager points fingers at them. Try to make the retrospective meeting an enjoyable experience. Be creative with this. The team likes pizza? Get them some!
  • Keep track of previous retrospectives and review results. This is important. The team will lose trust in and appreciation of the value of the meeting if action items are not applied and the owner (the ScrumMaster, in many cases) does not make any progress.
  • Prioritize action items. Handle these as you would product backlog items. Keep a backlog of impediments and action items, in prioritized order, to get the greatest value.
  • Timebox. Just as in other Scrum activities, you can benefit from timeboxing to get the most out of the retrospective meeting and keep the team focused on achieving the required outcome.


  • Play the blame game. This is not a flaming meeting where team members blame each other for the bad things that happened. Adopt a positive attitude toward the problems the team has. The objective is to get better.
  • Suppress feelings. If some team members feel depressed or unsatisfied because of some practices, give them some space to let these feelings out. Discuss them rationally instead of suppressing or denying them. Don't let the negative attitude control the meeting either; this can be done by getting suggestions and ideas instead of complaints.
  • Include uninvited external members. This is a team meeting. The PO or other managers should not attend unless invited by the team to discuss specific issues. Like couples, teams need some privacy.
I hope these few tips make your retrospectives better, and so your Agile journey.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.9 (21 ratings)


Tim Baffa, CSM, 7/28/2014 2:25:45 PM
Good points. I think a much-overlooked aspect of Sprint Retrospectives is around team-building. Better team collaboration by itself can result in significant productivity gains.
Saravana Bharathi, CSP,CSM, 8/5/2014 3:28:51 PM

You have brought a lot of good points. Especially encouraging introverts, making it a safe place to express etc. One point I would do is include the PO to be part of the retrospective, Retrospective is for the 'Whole' team including PO.
Hesham Amin, CSP,CSM, 8/9/2014 7:28:41 AM
Thanks Saravana
I agree, In general PO should attend as a part of the team.
Under some circumstances, some teams prefer not to include the PO. Cases like when the PO is external to the organization and not enough trust is built yet. In other cases the PO is from a Project management background and both the team and the PO still under the effect of the Command and control mindset, hence prefer not to include the PO.
I think inclusion of PO indicates a healthier team setup and generally desirable. And I should have mentioned the reasons not to include POs.
Anonymous, 8/11/2014 9:46:10 AM
Yes I Agree with Hesham Amin's Comments. PO Should not include in Retrospection Meeting.
Els Meyvaert, CSM,CSPO, 8/20/2014 3:59:55 AM
Great article, thanks!
Samir Umrikar, CSM, 8/27/2014 6:54:02 AM
Good Article. I think tracking retrospective actions is one of the most imp things. In a long running project having 2 weeks sprint, keeping each retrospective might be a challange and we need to have some gamification / fun.
Mark Alcantara, CSP,CSM, 3/31/2015 4:50:59 PM
I ran a search on retrospectives to get an idea on how others are successfully doing it in order to mix things up on my own project retrospectives. Very good points here.

One thing in particular I find challenging is motivating team members that purely want to focus on work. Demonstrating the value of team building with retrospectives is an up hill climb in these cases. Any one have success stories in situations like this?
Amanda Arseneau, CSM, 4/13/2015 12:26:00 PM
Great article Hesam, thank you for the post!
@Mark - I used to have this problem but I've found incorporating a more game like style to a retro here and there has helped immensely. For ideas you can check out I try to get everyone to write or do something individually and then discuss it as a team. At first the team may be a bit resistive, so reiterate that it's a safe space, if they don't want to share what they write down they don't have to, crack a lot of jokes (or try). It not only makes for fun retros, but when you have to discuss something serious or not so fun the openness has already been bred within the team and that timebox. Best of luck!
Mohammed Abrar, CSM, 6/10/2015 10:06:48 AM
I like the article, but I have conflicting views on inviting the PO to the retrospective or not. He/she is part of the team in terms of he/she holds 1 of the fundamental roles, so why treat this person as not part of the "team"? Yes, we separate the team, the scrummaster, and the PO but these 3 roles make up the TEAM.
Hesham Amin, CSP,CSM, 6/19/2015 4:22:36 AM
@Mohammed Abrar
You have a good point. PO is a part of the whole team.
The reason why in some cases inviting him to the retrospective meeting is beneficial is when the team is still in a transformation phase, where originally the PO used to be the project manager or any position that is considered of "higher rank" than the rest of the team.
In this case the retrospective might turn into a traditional reporting and members won't feel comfortable with mentioning the challenges and weaknesses.
Hesham Amin, CSP,CSM, 6/19/2015 4:24:50 AM
Correction: Regarding my previous comment, I meant "not beneficial".
Sureshchandra Sharma, CSP,CSM,CSPO, 5/19/2016 3:09:06 AM
Great note Hesham. Thanks for sharing.

I believe its more how the Scrum master able to build the relationship with team day in & out, that will make the retrospective simple and productive.

The ultimate key for success is to practice servant leadership day in and out for Scrum Master.

Happy reading and best wishes Scrum Master :-))
Chip Benedum, CSM, 6/24/2016 12:59:25 PM
I agree that the PO attends. They are either part of the team or they aren't. I consider them part of the team.
Gowri Goli, CSM, 8/25/2016 12:53:14 PM
Include uninvited external members. This is a team meeting. The PO or other managers should not attend unless invited by the team to discuss specific issues. Like couples, teams need some privacy.

I am confused with the above statement. PO or other managers? Does this mean PO is a Manager> Why PO should not be in the retrospect, can some one elaborate.
Shashank Katte, CSP,CSM,CSPO, 10/19/2016 4:53:35 PM
Great Article Thanks!
Eric Herr, CSM, 4/7/2017 12:40:14 PM
I disagree with this statement in part; "This is a team meeting. The PO or other managers should not attend unless invited by the team to discuss specific issues. Like couples, teams need some privacy."

Certainly program managers should not be included but the Product Owner is a MEMBER of the Scrum Team and should be included in the retrospectives. This is an area for the entire team to improve processes. If the PO is not present how is he/she to know where they fit into the process improvements. If you don't include the PO in your retrospectives your team really should start working on trust issues.

You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.



Newsletter Sign-Up