Software development teams, no matter the shape or size, should always take the opportunity to reflect on their ways of working. These reflections usually take the form of retrospectives, where you review past actions and activities, draw lessons from them, and apply the lessons to improve team morale and productivity.
The responsibility of conducting a retro typically falls on either a product or engineering manager. Regardless of who ends up running it, it’s important for product managers to understand these kinds of retrospectives and how they can improve the team’s culture, processes, and productivity.
One of the most productive retrospective frameworks is called “Start, Stop, Continue.” When used properly, it can not only help teams eliminate unhelpful practices but also increase productivity and team happiness. Let’s learn more.
Before diving into what the Start, Stop, Continue framework is, we should first go over what makes a retrospective. In a nutshell, a retrospective is a team-wide review meeting that usually occurs at the end of a sprint or after shipping a feature.
The purpose of a retrospective is for team members to review, collaboratively, what went right or wrong with their last sprint. It’s a time to discuss if they had concerns regarding certain actions or behaviors and what kinds of improvements they should make, as a team, to not face those issues again.
The hope is that any issues that have been percolating over the last few months are nipped in the bud before they escalate. The overall collaboration, culture, and productivity of the team will hopefully improve as well. Modifying practices will hopefully help the team ship more high-quality features quicker and at a more agile pace.
As the name suggests, the Start, Stop, Continue retrospective is one of the many retrospectives out there. What makes it unique, however, is its direct approach.
Typically, most retrospectives ask team members to augment their feedback with examples of things they would like to avoid in the future. Doing things this way might take longer, as team members have to come around to the point they are trying to make. This is not a very efficient use of time, especially when retrospectives typically only last for one or two hours.
The Start, Stop, Continue framework avoids this by asking feedback from team members on three different aspects:
As we just highlighted, the Start, Stop, Continue framework has a lot of great benefits. Let’s go over the biggest points below:
Unlike other retrospectives, the Start, Stop, Continue framework revolves around a direct approach that favors more robust discussion around action points. This differs from other frameworks that ruminate on particular situations that came up before, specifically ones that the team may not be able to draw lessons from since it was so long ago.
By asking the team directly what kind of actions they want to start, stop, or continue, the discussions focus on the tail end of what’s important — the type of behavior the team should express and apply in the future. It also helps with saving all the required time to engage in retrospective discussions.
As we talked about, the questions from the Start, Stop, Continue framework are not only focused on the actions that can be taken now but are also future-oriented. The actions should be implemented immediately and measured to see if they bring the positive change the team wants.
Being future-oriented helps assure the team that decisions made during the Start, Stop, Continue retrospective will be respected and implemented. It also gives each member the confidence to voice their individual concerns.
Finally, Start, Stop, Continue can be used by teams to focus clearly on the outcomes they set out to achieve. This can differ from other retrospective formats that sometimes dwell too much or too deeply into awkward situations that cropped up during the last sprint.
By asking what they should start, stop, or continue doing, the discussion can start to revolve around the outcomes that each team member is looking for rather than wasting time talking about past situations.
Conducting a Start, Stop, Continue retrospective is not just about ensuring the team gets together and lists down suggestions, and then calling it a day. There needs to be space for the team to really hone in on specific actions to undertake, continue, or stop based on their experience with the last sprint.
When thinking about the actions under Start, Stop and Continue, it’s important that team members keep these questions in mind all the time. The questions should prompt team members to constantly think about what might be helpful to start, stop, or continue for the future culture of the team.
Each section has its own questions that each member can think about before listing their suggestions, such as:
The following are the steps to ensure the smooth, effective running of the Start, Stop, Continue retrospective for your team:
Apply the above steps and you’ll be undertaking the Start, Stop, Continue framework for retrospectives like a product manager in no time.
Until next time!
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Mike Korenugin, Director of Product at SE Ranking, shares the importance assuming a data-informed approach.
Priya Lakshminarayanan, Chief Product Officer at Recurly, talks about Recurly’s work to improve merchants’ subscriber experiences.
Phil Freo shares his experience scaling Close from its founding team to more than 100 people and transition to being a fully remote company.
Nick Fisk shares his experience leading transformations and transitioning companies to a product ownership model.
Learn more →
