Reading Time: 4 minutes

Is your team bored with the way you do your retrospective meeting? Is it always the same after every sprint? Then why don´t you try something new?

I recently found a nice article from Mike Cohn about a format of sprint retrospectives, which I haven´t heard before – the Start-Stop-Continue retrospective.

At first for those, who don´t know what a retrospective meeting is: In a retrospective meeting the team comes together and discusses the things, which went well and which went not so well during the last sprint. Then they come up with some action points, what they want to improve in the upcoming sprint.

Ok, and what is this new Start-Stop-Continue all about?

Start-Stop-Continue retro

At the beginning you draw three columns on the whiteboard: Start, Stop, Continue. Then you give the team some time to write down on sticky notes, what they want the team to start doing, stop doing or continue doing in order to become a better team.

Start and stop doing things is obvious: For example, someone might want the team to start monitoring application logs, another want to stop the team for having daily standups lasting for longer than 15 minutes.

In the continue section you put things, which the team has already done a couple of times, but are not yet so deep-seated within the team. For example, in my team we started with timeboxed refinements, but it is still quite new and we don´t always set the alarm clock, when discussing the user stories and tasks during refinement meeting. Therefore “timeboxed refinments” might become an action point in the continue section.

After everybody has written down his/her proposed action points, you stick them on the whiteboard and you run through each item in the list, having a discussion with the team. Then, when everybody knows, what each item is about, the team is going to vote, which action points you want to pick up for the upcoming sprint.

Dot-Voting

For voting we use a simple method called dot-voting. Here every team member gets a certain amount, let´s say 5, virtual dots, which he/she can use for voting. Everybody gathers together in front of the whiteboard and marks the action points with dots, you can place all your 5 dots on only 1 action point, but you can also distribute them over multiple items – for instance you can place 2 dots on the first action point and 3 dots on the second action point.

When everybody has placed his 5 dots, then the scrum master orders the action points according to the number of dots. Finally the action points with the most dots are picked up and set as a goal for next sprint.

Don´t pick up too many items, probably only 2 or 3, so the team can focus on those. If you pick up too many, then the team might loose the focus and forget, which items were picked up.

Technical-Communication-Personal sprint retrospective

In my team we used to do another format of sprint retrospective during the last couple of month, the Technical-Communication-Personal retrospective format. I got the idea for that format from the book Memoirs of a Software Team Leader.

We had 3 sections on the whiteboard, which were Technical, Communication and Personal. Everybody silently wrote down on a sticky note, what he/she liked and disliked in the sprint and then those sticky notes were placed in one of the 3 columns on the board. In addition, each column had one row for positive feedback and another row for negative feedback.

In the technical column we put issues or achievements, which we had from a technical point of view. For instance, the sprint was delayed, because we underestimated the challenges we had when introducing a new framework.

Examples for the Communication column are for instance, because of a communication issue a certain task was misunderstood and implemented incorrectly. Or, “I feel we had a great collaboration with another team during the sprint“.

In the Personal column you put things, which concerns yourself or another person specifically. For instance, “I really appreciate that Adam helped me out with a certain task, which I was not able to solve by myself“. Or “I really feel bad, that I didn´t realize earlier in the sprint, that I am on the complete wrong path for that new module. I should have asked for help“.

Finally, when everybody finished writing down the items on the sticky notes and placed them in the correct section on the whiteboard, the team runs through each item, usually resulting in a good discussion. During that discussion you identify action points for the upcoming sprint to improve the working of the team.

Difference

Now as my team has done both retrospective formats, the Technical-Communication-Personal and the Start-Stop-Continue format, I can clearly see some differences in the outcome.

The biggest difference is, that in the Technical-Communication-Personal format you end up with a lot of sticky notes on the whiteboard. When you run through them together with the team, it usually results in a nice and long discussion. But it is not so easy to identify action points during that discussion. Sometimes we end up with 10 or even 15 minutes of discussion for 1 sticky note, but we cannot define an action point after that. Of course, this discussion is usually somehow helpful for the team, but on the other one might see it as a waste of time, if there is no ouput.

In the Start-Stop-Continue format you end up with a lot less sticky notes on the board, but each of it is an action item by itself. This means, that there are fewer topics to discuss, but each discussion starts already with what a team member wants to achieve.

One final tipp from Mike´s blog I mentioned earlier: Don´t pick up too many items, which you want to address in the upcoming sprint, because this might distract the team. Don´t pick more than 3!

Ok, that´s it for today. Stay tight and HabbediEhre!