The “start, stop, continue” retro is an agile retrospective technique that almost every scrum master and project manager knows as a must-have tool for agile retrospective meetings. It is known as an action-oriented retrospective style that supports continuous improvement of your agile collaboration.
But all that glitters is not gold: There is something about this method that we do not like and it has to do with the order of the steps. Let’s dive in why we think it is not reasonable from a psychological point of view.
In order to explain to you why the “start, stop, continue” exercise sucks and what you should do instead we’ll provide you further insights in what this agile retrospective technique contains and how it can be improved.
What is the “start, stop, continue” Retro?
The “start, stop, continue” exercise is a technique that can be implemented in agile retrospective meetings and is used to review the actions and outcomes of your last sprint in order to derive suggestions for future improvement. The basic concept of this exercise is to discuss three main questions:
Start: What is working?
Stop: What isn’t working?
Continue: What has proved successful?
By answering these three questions you can reflect on your working behaviours and choose whether to keep or dismiss them. This helps easing the processes and working out best practices for your team.
You may wonder now: What’s wrong with it then?
Why the “start, stop, continue” Retro sucks
Saying something sucks might seem a little harsh at first. But you’ll soon get what we mean with it. The basic concept of the “start, stop, continue” exercise is good and is similar to other agile retrospective techniques: The team tries to figure out what is working well, what is not and what they want to try out in the next sprint.
The problem of this exercise is the order in which the categories are discussed:
Start: This category contains activities the team will begin doing in the next sprint.
Stop: This category looks back at the previous sprint in order to identify things that didn’t work out and therefore should be dismissed.
Continue: This category reviews things that worked out in the last cycle and should therefore be kept doing and part of the core activities of the team.
The problem with this order is that before reviewing your last sprint, suggestions for future improvement are made. This is psychologically unreasonable, since the proposals for the start category are derived from the other two categories. Despite that it is always good to start with positive feedback on elements that are already included in your working routines. This motivates your fellow members and ensures a pleasant start of the exercise.
What you should do instead
Since we not only want to criticize, but also show you how to do it better, we will now explain what you should do instead. The order we recommend is: Keep – Stop – Start.
This category should be used to discuss behaviours that have been used already and were successful but aren’t part of common practice yet. To find these out you can use questions like:
- What went well in the last sprint?
- What helped us reach our goals?
- What was successful in the last sprint?
- What do I want to use more regularly?
Starting with “keep” has two main advantages: Firstly, you’ll head in with positive aspects of your agile collaboration. This betters the mood of your team members and provides an enjoyable atmosphere. Secondly, you’ll start with reviewing your past behaviours and analyse the upsides of it. This is a great opportunity to become aware of these behaviours and integrate them into your routines.
This category should be used to discuss past behaviours that have been used already but hindered your team in reaching your goals. In order to identify these disadvantageous behaviours questions like the following can be asked:
- What went wrong in the last sprint?
- What made me feel uncomfortable?
- What slowed us down?
- What kept us from reaching our goals?
Discussing “stop” after “keep” is useful because negative aspects should never be ignored. You can see this category as the opposite of the first one. Talking about negative behaviours is always a little uncomfortable but it is really effective. When you compare negative and positive behaviours you can define specific plans and implement them in future sprints.
Last but not least, you and your team members are supposed to discuss the category “start”. This category is used to define plans and behaviours you want to implement in your next sprint. These are things you haven’t done before or you’ve done very rarely. To find out what you want to implement you can use questions like:
- What do we want to try in the next sprint?
- What could possibly help us reach our goals?
- What could help us be more successful?
You discuss this category in the end because seeing what helped (keep) and didn’t help (stop) you is helpful in deciding what is still missing. By talking about behaviours that could potentially support your team in being more successful you’ll break out of your comfort zone and improve your agile collaboration. Therefore you get a view of what you can still achieve.
How to design a “Keep, stop, start” Retro
Similar to other agile retrospective techniques you’ll go through different phases while running this exercise.
In Silence! Don’t influence each other.
- Combine similar ideas
Talk about the ideas and merge similar topics.
- Vote on the ideas
Use dot-voting in order to decide which topics you want to discuss.
Discuss the different topics of each category.
Make sure that every team member has a say in this and that no one feels left out. Be aware of defining the topics of each category specifically so that everyone knows what exactly they gotta work on.
In Summary: The “Start, Stop, Continue” Retro – why it sucks and what you should do instead
The “Start, stop, continue” exercise is in its essence a useful exercise if the order of the categories to be discussed is changed to “Keep, Stop, Start”. It can help your team implement agile retrospectives into your daily work. Nevertheless, there are still more possibilities to create retrospectives in order to work agile. If you want to gain further insights in other agile retrospective techniques you should check out our articles about the Starfish Retro format and the Sailboat Retrospective.