7 DOs and DON’Ts of Sprint Retrospective

There are quite a few issues that many Scrum Teams struggle with while doing Sprint Retrospective. In this article, I want to drop you some hints on how to run a valuable Sprint Retrospective.

1. DO run a Retrospective meeting at the end of every Sprint

Usually, I hear two reasons why teams skip the Retrospective. The first one is: “We did not have enough time because there was too much work to be done”. And the second: “Why should we do a Retrospective? Everything works fine”. In both cases, teams lack understanding of what Retrospective is for and both are utterly wrong. If you cannot find 45 minutes a week, or 3 hours a month, to talk about your process and make improvements to it, you (usually) do not pivot your processes at all. As a result, you run into a vicious circle: 

  • You have too much work to improve and optimize your processes.
  • You do not optimize and improve your processes because you have too much work.

This leads to a very simple outcome: you will not improve the way you work. This approach usually takes place when people do not believe that the Retrospective can bring them any value compared to the value they can deliver if they spend that time working. Another problematic approach is when you believe that the only reason Retrospectives are held is to deal with problems and failures. Some people think that if a Retrospective is needed they admit they have a problem. 

On one hand, a retrospective is not a way of dealing with failures, although it can be used as such. During a retrospective, positive behaviour and well-executed processes should also be discussed and teams should look for ways to reinforce them. On the other hand, there is always an issue in the team, project or process that can be addressed. Usually, the question is not: “If we have any issues?”, but more probably: “What issues do we have?” A Retrospective helps answer that question.

2. DON’T turn the Retrospective into witch hunt

The goal of a Sprint Retrospective is for the team to come up with improvements that can be implemented during the next Sprint. This can be done only when the team feels comfortable discussing their problems in a civilised manner. If the meeting will turn into a witch hunt, people will become defensive, uncooperative and in some cases even hostile. Negative emotions and feelings towards team members will destroy team spirit and can be a threat to future collaboration. 

3. DO make Action Points during each Retrospective

To let the team find improvements that can be implemented during the next Sprint it is necessary and crucial to discuss multiple topics during the Sprint Retrospective. However, each discussion should lead to an improvement or multiple improvements that the team will commit to. Otherwise, the team may feel that their efforts don’t make any difference and are wasting their time to ‘idle talks’ and will not want to engage in further Retrospectives. 

4. DON’T let others know what the team has discussed during the Retrospective

Unless decided otherwise: what happens during the Sprint Retrospective – stays within the team. Many people will have objections to speaking their mind if everything they say will be revealed to other people without their consent. That is why the team must be 100 percent sure no-one will learn what they have talked about at the Retrospective and they can share their opinions openly without unnecessary consequences.

5. DO make S.M.A.R.T. Action Points during each Retrospective

  • S – Specific – you want your team to focus on one item/behaviour/improvement – not on a generic idea.
  • M – Measurable – when you decide to take any action, you want to know if it helps to improve anything or to achieve a goal – that’s why you need to find a way to measure how the things are going.
  • A – Achievable – you don’t want to chase perfection forever. It is very discouraging if you can’t take an action or achieve a goal. Sooner or later you will give up.
  • R – Relevant – if you want to take an action – choose one that really matters at the moment.
  • T – Time-boxed – set a deadline – you do not want to have a ‘list of improvements’ that ‘will be implemented someday’.

6. DON’T repeat the same meeting pattern for each Retrospective.

A Retrospective is all about creativity. It is the only Scrum meeting that should not have an agenda carved in stone. Each Retrospective should be different from the previous ones. Of course, nothing wrong will happen if once or twice a year assignments during the meeting will be repeated but don’t do it too often. You want your team to take a creative approach to looking for better ways of working together and delivering value in a more Agile way.

7. DO ask your Product Owner to participate in the Sprint Retrospective

The Product Owner is a member of the team as well. He or she will have a different, unique perspective on the teams’ work. Usually, they will also have a valuable input during the Sprint Retrospective.

In addition to that, the Product Owner will be able to understand the development team better if they get to know their problems and issues they need to deal with. It will let the Product owner better understand and therefore better cooperate and communicate with the development team.


Retrospectives are a crucial part of the Scrum team lifecycle. They are not only helping to build the team spirit but will enhance communication and encourage collaboration on multiple levels. If conducted properly – they may be the difference between “worst project in the company” and “project that everyone wants to work in”. What are your experiences with retrospectives? Do you enjoy them? Do you hate them? Please leave a comment below and let us know.


Aspire Blog Team

Aspire Systems is a global technology services firm serving as a trusted technology partner for our customers. We work with some of the world's most innovative enterprises and independent software vendors, helping them leverage technology and outsourcing in our specific areas of expertise. Our services include Product Engineering, Enterprise Solutions, Independent Testing Services and IT Infrastructure Support services. Our core philosophy of "Attention. Always." communicates our belief in lavishing care and attention on our customers and employees.