Skip to main content

About retrospectives...(reading time 2 mins)

Last post 12:50 pm April 30, 2019 by Michael Bailoni
No replies yet
12:50 pm April 30, 2019

Hi all,

we all know what the sense of retrospectives are. There is a ton of literature available.

Nevertheless, I want to share my knowledge and experiences with you - main goal is not to do good retrospective, but to do really great retrospectives - even better than they are now - with you guys.

First point: INSPECT and ADAPT --> we all agree to that point, right?

What really helps is to share knowledge and experiences!

Some hints, experiences…


*) Take notes / gather data during the sprint (what do you like to discuss with your team?) --> in the meeting you have less time to think about, and maybe important things will stay hidden.

*) Give constructive, honest Feedback to each other (what do you expect from each other / from the product owner / from the Scrum Master...).

*) Try new things for the next sprint and see / evaluate whether there was a benefit gain or not (e.g. TDD...).

*) Think about process, people, communication, tools (maybe you had good experiences in former companies with other tools). Share it with your team! Learn from each other!

*) Work on the self-organization (in the past, I saw a lot of Scrum-Masters (including me) taking notes about actions / responsibilities and put it on the white-board) -->if you find yourself doing it like that, try to change it for the next retro. A member of the dev-team should take over.

*) Try to keep the permanent agreements at all time. Inspect and adapt them as well - maybe things changed over time.

*) It’s a team-meeting --> you do it for yourself (to grow as a team, to find and eliminate weak processes), you don’t do it for your scrum-master 😊, at least not only, because he is part of the team.

*) Take your time in the meeting, focus on the meeting and eliminate distractions (like mobiles, laptops,….). --> I often saw distracted team-members, this will "kill" your retrospectives.

*) If weather is nice try to organize an outdoor-meeting. --> I have great experiences with that, nature can help to be more creative and it will probably open your minds). --> it can help people to calm down and concentrate / focus on one thing!

*) See the meeting as a chance not as a burden. --> in the past I saw a lot of teams getting bored doing retros, because there was no real output, or the agreements and actions were not adhered by the team.

*) Have fun during retros, life is serious enough, right?

*) Work together on the quality of your retrospectives. Its not only the Scrum-Masters task.

*) Change the approach of your retrospectives to make them more exciting.

*) Invite the Product Owners to the meeting. (especially for new teams it's a must). Talk about how to communicate, how to build the backlog, the product backlog items,...). I saw a lot of teams "failing" because the product owners were not part of the meeting. They are part of the scrum-team so its necessary that they join the meeting and help improving at any front.


Thanks for reading,

Cheers, Michael

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.