I’ve been running Sprint Reviews for the last 15 years, and I truly believe them to be useful when done well. When Sprint Reviews are not done well, however, they are at best a waste of time and at worst give you a reduction in morale. Pre-requisites For Sprint Retrospectives to be effective, you have to adhere to the basic rules of setting up a good scrum team: Scrum Teams should not be too big. No more than 6 people. If they are larger than that, split them. It’s harder to build team-wide trust with a larger team. A safe and open environment: You will get nothing out of a retrospective if people are afraid to speak their minds. Without real input, you will not get good actionable outcomes. Actioning: If you and your team do not put into effect the outcomes of your retros, people will lose faith and stop participating. Right. Now that we’ve got that out of the way, let’s look at the process. What is a Start, Stop, Continue Retrospective? As the name suggests, this approach focuses on three simple questions for the team: What should we start doing?


What should we stop doing?


What should we continue doing? This framework cuts through the noise and focuses directly on actionable changes. Let me break down how I run these effectively. The Process When team members suggest "start" items, they're looking at practices or behaviors we should add to our workflow. These might include: Getting customer feedback on features earlier
Setting up acceptance tests with stakeholders before coding
Implementing code reviews
Being punctual for standup meetings
Focusing on finishing stories before picking up new ones The "stop" list captures inefficiencies or time-wasters. Common examples I've seen teams identify: Committing code without ensuring tests pass


Letting daily scrums run longer than 15 minutes


Skipping refinement sessions when we feel behind schedule The "continue" section highlights positive practices that aren't yet habitual. Items from either the start or stop categories can move here once they're being implemented but need reinforcement. Once something becomes second nature to the team, we remove it from the list to keep it manageable. Mixing Up the Format To prevent “retrospective fatigue” (it’s real, believe me), I vary how we collect ideas: Sometimes, I'll simply open the floor for suggestions in any category


Other times, I'll go around the room, asking each person to contribute one item


When I notice specific issues, I might focus exclusively on "stop" items first


Occasionally, I'll combine approaches, going person-by-person for one category, then opening up for general discussion This flexibility keeps the format fresh even after many sprints with the same team. Making Decisions When idea generation slows down, it's time to vote. I typically use multi-voting - giving each team member three votes they can use as they wish. I prefer multi-voting because many retrospective actions don't actually require additional time - they're behavioral shifts. For example, being punctual for standups doesn't consume time; it saves it. Multi-voting allows us to select 2-3 key focus areas without overwhelming the team. We also review the "continue" list to see if any items have become habits or are no longer relevant. Setting Up for Next Time For the following retrospective, I bring a large sheet with all the previous ideas - both chosen and not chosen. I don't make a big deal about it - I simply tape it to the wall as a reference point. Then we begin a fresh start, stop, and continue the discussion. Why This Approach Works In my experience across various companies and team structures, this method is efficient, accessible, and productive. It's action-oriented rather than feelings-focused. Compounding is well known in the financial arena but is very rarely mentioned when it comes to team improvement. Team Retrospectives allow you to make little changes over a long period of time. If you compare the morale and ability to deliver in a team over the course of a year, with the right retrospectives in place and happening regularly, I would expect to see a large and positive change. While understanding emotions can be valuable in some contexts, this approach gets straight to behavioral changes. Every item generated leads directly to an action: starting something new, stopping something ineffective, or continuing something valuable until it becomes ingrained. For teams that value practical outcomes over extended discussion, the start, stop, and continue framework delivers consistently strong results. I’ve been running Sprint Reviews for the last 15 years, and I truly believe them to be useful when done well. When Sprint Reviews are not done well, however, they are at best a waste of time and at worst give you a reduction in morale. Pre-requisites For Sprint Retrospectives to be effective, you have to adhere to the basic rules of setting up a good scrum team: Scrum Teams should not be too big. No more than 6 people. If they are larger than that, split them. It’s harder to build team-wide trust with a larger team. Scrum Teams should not be too big. No more than 6 people. If they are larger than that, split them . It’s harder to build team-wide trust with a larger team. split them A safe and open environment: You will get nothing out of a retrospective if people are afraid to speak their minds. Without real input, you will not get good actionable outcomes. A safe and open environment: You will get nothing out of a retrospective if people are afraid to speak their minds. Without real input, you will not get good actionable outcomes. Actioning: If you and your team do not put into effect the outcomes of your retros, people will lose faith and stop participating. Actioning: If you and your team do not put into effect the outcomes of your retros, people will lose faith and stop participating. Actioning: If you and your team do not put into effect the outcomes of your retros, people will lose faith and stop participating. Right. Now that we’ve got that out of the way, let’s look at the process. What is a Start, Stop, Continue Retrospective? As the name suggests, this approach focuses on three simple questions for the team: What should we start doing? What should we stop doing? What should we continue doing? What should we start doing? What should we start doing? start What should we stop doing? What should we stop doing? stop What should we continue doing? What should we continue doing? continue This framework cuts through the noise and focuses directly on actionable changes. Let me break down how I run these effectively. The Process When team members suggest "start" items, they're looking at practices or behaviors we should add to our workflow. These might include: Getting customer feedback on features earlier Setting up acceptance tests with stakeholders before coding Implementing code reviews Being punctual for standup meetings Focusing on finishing stories before picking up new ones Getting customer feedback on features earlier Setting up acceptance tests with stakeholders before coding Implementing code reviews Being punctual for standup meetings Focusing on finishing stories before picking up new ones The " stop " list captures inefficiencies or time-wasters. Common examples I've seen teams identify: stop Committing code without ensuring tests pass Letting daily scrums run longer than 15 minutes Skipping refinement sessions when we feel behind schedule Committing code without ensuring tests pass Committing code without ensuring tests pass Letting daily scrums run longer than 15 minutes Letting daily scrums run longer than 15 minutes Skipping refinement sessions when we feel behind schedule Skipping refinement sessions when we feel behind schedule The "continue" section highlights positive practices that aren't yet habitual. Items from either the start or stop categories can move here once they're being implemented but need reinforcement. Once something becomes second nature to the team, we remove it from the list to keep it manageable. Mixing Up the Format To prevent “retrospective fatigue” (it’s real, believe me), I vary how we collect ideas: “retrospective fatigue” Sometimes, I'll simply open the floor for suggestions in any category Other times, I'll go around the room, asking each person to contribute one item When I notice specific issues, I might focus exclusively on "stop" items first Occasionally, I'll combine approaches, going person-by-person for one category, then opening up for general discussion Sometimes, I'll simply open the floor for suggestions in any category Sometimes, I'll simply open the floor for suggestions in any category Other times, I'll go around the room, asking each person to contribute one item Other times, I'll go around the room, asking each person to contribute one item When I notice specific issues, I might focus exclusively on "stop" items first When I notice specific issues, I might focus exclusively on " stop " items first stop Occasionally, I'll combine approaches, going person-by-person for one category, then opening up for general discussion Occasionally, I'll combine approaches, going person-by-person for one category, then opening up for general discussion This flexibility keeps the format fresh even after many sprints with the same team. Making Decisions When idea generation slows down, it's time to vote. I typically use multi-voting - giving each team member three votes they can use as they wish. I prefer multi-voting because many retrospective actions don't actually require additional time - they're behavioral shifts. For example, being punctual for standups doesn't consume time; it saves it. Multi-voting allows us to select 2-3 key focus areas without overwhelming the team. We also review the "continue" list to see if any items have become habits or are no longer relevant. Setting Up for Next Time For the following retrospective, I bring a large sheet with all the previous ideas - both chosen and not chosen. I don't make a big deal about it - I simply tape it to the wall as a reference point. Then we begin a fresh start , stop , and continue the discussion. start stop continue Why This Approach Works In my experience across various companies and team structures, this method is efficient, accessible, and productive. It's action-oriented rather than feelings-focused. Compounding is well known in the financial arena but is very rarely mentioned when it comes to team improvement. Team Retrospectives allow you to make little changes over a long period of time. If you compare the morale and ability to deliver in a team over the course of a year, with the right retrospectives in place and happening regularly, I would expect to see a large and positive change. Compounding While understanding emotions can be valuable in some contexts, this approach gets straight to behavioral changes. Every item generated leads directly to an action: starting something new, stopping something ineffective, or continuing something valuable until it becomes ingrained. For teams that value practical outcomes over extended discussion, the start, stop, and continue framework delivers consistently strong results.

Continue

effect

Every

The Best Sprint Review Schedule for Agile Success

How to Get the Most Out of Your Sprint Reviews 

Read My Stories

CalculatorLord

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

The Most Effective Way to Run a Sprint Retrospective

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

ACE Your Software Engineering Interview With a Few Tips

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

ACE Your Software Engineering Interview With a Few Tips

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps