The start stop continue method

What is the start stop continue method?

Start stop continue or start stop keep, at its core, is a method used to regularly reflect on ongoing events for a certain timeframe in which performance is evaluated. This is clearly shown by the three components it uses to structure thoughts. Let's break them down:

• Continue or keep is used to highlight strengths and/or things that went well in the timeframe that is being reflected on. Additionally, continue also suggests there's a future timeframe. Items that fall in the continue category are thought to also lead to success in the future.
• Stop is used to indicate things that blocked or decreased performance during the past timeframe. The stop category is not meant to be a direct action item i.e. it might not be possible to simply stop doing the things filed under this category. The items in the stop category should rather be used to start a discussion for action items.
• Start is used to raise new idea's or behavior that can improve performance in the future. It's important to note that items in the stop category can often also be represented by an idea to address that issue.

Now that we understand the main components of the start stop continue method, it's clear why it has become so popular in agile organizations. Agile values transparency, regular feedback and continuous improvement and start stop continue provides an easy framework to structure regular conversations around performance. Therefore, start stop continue is often used for collecting 360 degree feedback from peers, structuring 1:1 feedback to a direct report, giving bottom-up feedback to a manager and in scrum teams for the retrospective at the end of the sprint.
In the next sections, we'll dive a bit deeper into those specific use cases and provide tips and examples for using the start stop continue method effectively.

Using start stop continue for giving individual feedback

How to use start stop continue as a manager

As a manager, start stop continue provides a simple model for collecting feedback from the peers of your direct report f.e. as part of a 360 degree review. As described above, it helps peers structure feedback in a way to raise things positive (continue) and negative (stop) points and leaves room for suggestions (start) all in the context of continuous collaboration and regular feedback gathering.

Collecting feedback
The collection of this feedback can be done, by directly asking people through email or by direct message, but also by sending a simple Google Form as shown below:

In the settings tab, you can control whether to collect the responses anonymously or not. I'd suggest turning on the setting to limit the responses to 1 per recipient, but to encourage open and honest feedback not collecting the email addresses.

You can access the sample form here.

Processing peer feedback
After the employees' peers have provided you with their feedback, it's up to the manager to go through the it. As a manger, try to spot both patterns in the feedback that point to the same behavior or characteristic, as well as pieces of feedback that contradict each other. The pieces of similar feedback will help you with either something to praise your report for or provide an area where adjustment is required. For the latter, try to come up with some ahead of delivering the feedback.
Depending on whether you want to share all individual feedback items directly with your report, you can also summarize the different pieces of collected feedback.

Delivering feedback
Right before delivering feedback to your report, give them a chance to go through either your summary or the full feedback collected and ask them to reflect on it for a while. Timing is important here, the sweet spot is usually an hour or two, which is long enough for the employee to properly think things through while also not being long enough for the employee to overthink things that need context and discussion.
As a manager, I suggest to start the meeting with the employee's self-reflection on the feedback. See yourself as a coach helping them contextualize the peer feedback and, from the preparation you did yourself ahead of the meeting, make sure to openly praise the good feedback, as well as suggest action points for improvements in the next evaluation timeframe.

Examples of start stop continue feedback

Below you can find some examples of what your employee's peers could raise to you as a manager using the start stop continue method:

Continue

• This developer great at onboarding our new team members. They are always available for questions and pair-programming sessions.
• This product manager prepares detailed tickets ahead of the refinement.
• This product manager protects the team well from stakeholders coming with distracting feature requests.

Stop

• This developer tends to expand the scope of his tickets by doing unnecessary refactoring work, leading to delayed delivery of features and the team not making the goal.
• This product manager often changes the scope of a ticket during implementation in a sprint. For an optimal workflow, we should rather file a separate ticket.

Start

• This developer should consider speaking up more in the refinement meetings. From personal discussions, I know he has great idea's.
• I would like it if the product manager provides us with a bit more business context, so the team has a better understanding of why we're building these features.
• This developer should make sure they take more initiative writing up a ticket when they have a new idea.

Using start stop continue for scrum team retrospectives

Retrospectives in Agile software teams

The retrospective, a.k.a. retro, is one of the cornerstone rituals for both agile teams that use scrum as well as kanban. As explained in the introduction, the start stop continue method is useful to reflect on ongoing events at the end of a timeframe in which performance is evaluated. In scrum this timeframe intuitively maps to the length of the sprint. In kanban, it's up to team to define how often they want to check-in on their performance.
The performance of an agile team that is being reflected on in the retro can be summarized as "Did we achieve the sprint goal we set ourselves in the planning meeting?". The answer to that question will typically correlate with other, more practical, indicators of performance like: high sprint velocity or high sprint completion rate, low amount of bugs, good collaboration in the team, accurate estimations, no unexpected blockers etc.
There's many different formats for retrospectives, but they all have similar goals: look back at the past timeframe, be transparent about performance and facilitate alignment of the group for improved performance in the next timeframe. In this article, we'll dive into more detail on start stop continue retrospectives.

The start stop continue retro

The start stop continue method is one of the most popular formats for agile retrospectives. A typical retro using this format would be scheduled at the end of the sprint for 30-60min. It is attended by the full scrum team, including the product manager, all developers and testers. It is usually facilitated by a scrum master, or a (rotating) team member. The facilitator isn't meant to put forward any new idea's, but instead facilitate discussions and make sure the meeting stays within the planned timeframe. A start stop continue retro typically has the following four phases.

Brainstorming
All team members, individually, take some time to reflect on the past timeframe and write down some notes in the three different categories.

Idea sharing and grouping
After all team members have completed their notes, the facilitator pulls the team together around a board (online or offline) that has area's for the start, stop and continue categories. Next, the team members, one after another, share their notes by putting them in the categories on the board. They may also give some extra explanation to ensure every team member understands what's meant. If team members as additional questions, it's important for the facilitator to keep the discussion to clarification only. Further discussion of the idea's will come at a later stage in the meeting.
It's common that different team members come up with similar idea's while reflecting on the same sprint. For those cases, group the similar notes together, so they can be used as a group for the next phase of the retro.

Voting a.k.a. Dotmocracy
After all notes have been shared and clarified, as well as duplicates grouped, it's time for the voting round. In this round, all team members get a certain number of votes to indicate the notes they think are most important to further discuss in the team. A member can cast multiple votes on one note and, given they indicate things that went well and that the team wants to keep, the continue idea's are not the best candidates for further discussion.

Defining action points
Once all votes have been cast, the facilitator counts them and orders the notes with the descending number of votes. The rest of the retro is used for more detailed discussion and definition of action points for the team as a whole or specific members. The facilitator needs to make sure the discussion stays on track, such that the team covers not just one note. They should also make sure the action points get documented.

Examples of start stop continue retrospectives

Continue

• Sharing the list of tickets before the refinement and adding questions.
• Take over the ticket from team members that are out sick, in order to achieve the sprint goal.

Stop

• Underestimating the tickets for Module 123
• Overrunning meetings and take certain discussions offline

Start

• More pair programming sessions with new-joiners
• Planning documentation tickets as part of the sprint.

Action points

• Product manager to share list of tickets ahead of the refinement meeting such that the team can prepare better
• Everyone to raise it when a detailed discussion should be taken offline such that meetings can end in time