Retrospection Start-Stop and Continue Methodology in Agile

Retrospective story

We generally follow the retrospective within the engagement / team on a weekly or fortnightly basis. I thought to write this article to explain what retrospection actually is. Somewhere it's part of agile methodology. Retrospection generally takes in consider after the release of each sprint (for example sprint is a time of release a build with some feature). The English meaning of retrospection is “Look back upon”, in other words go through with the work you have done in the past and review it.

I thought to implement some formal retro technique within project engagement. I studied plenty of methodologies and thought to introduce the simple and easy to adopt Agile Retrospection in a project. After brainstorming pertinent things I named the methodology “Start, Stop and Continue”.

The Start-Stop-Continue methodology and how to implement it in a project

It's a very simple approach, this retrospection technique is detailed as in the following paragraph with the procedure to implement it in project sprints. Kindly have a look at the following image:



Start-Stop-Continue: What is working well and should continue doing, what is not working well and it should be stopped and what is an area that can be explored or started as a new practice.

Each team member shares their thought one-by-one on each point relevant to the recent build or sprint and decides an action step. For example, a team member can share his/her view to focus on identifying something to stop or other team member can share his/her view to start a new practice in favor of a project to improve results.

Fishbone Analysis: These are a few key points that should be considered during retrospection.



After the initial discussion of this, the team will commonly vote or brainstorm on specific items to focus on during the future sprint or build. Some teams may consider having many discussions and debates. It’s useful to have a debate on what you are planning to do. The only downside of debates in retrospectives is that more vociferous attendees may overpower others. Hence, the Scrum Master (or facilitator depending on our practice) must be really good to remove all impediments. The key thing to remember during retrospection is not to blame anyone on a specific point.

Note: The next retrospection is often started with reviewing the key points (that were selected for attention) considered in the prior retrospective meeting.

This could be a formal or informal practice, like it’s not mandatory for the team to discuss it only in a conference room, the team may discuss these points anywhere, like “Chai pe charcha” during “Lunch” and other stuff, whatever the team likes. The team can start a discussion on the last spring or last build deployed on the production server. They may use a whiteboard to list all the points that can be the best fit in this model and brainstormed together. After discussion, collect some consolidated points as specified in the following diagram. These points are very generic to projects, it may vary depending on the project.

Kindly have a look at the following image that describes the start, stop and continue methodology with a practical approach in a detailed manner. Note: this is just an example.



Sprint Template table: This is just an example of a sprint task table.