The What Went Well Retrospective is a simple and effective way of organizing your end of sprint retrospective . It’s easy to understand and follow and means exactly what it says. It breaks down the events and actions of the sprint into two parts. Forcing the team to think hard and put everything into a “went well” and “not well” column leaves no room for ambiguity.
What Went Well
All the things that help the team in reaching its goal for the sprint are part of this. It is also an opportunity to give kudos to people in your team who did something you appreciate. Let’s look at some examples:
1.The end of the sprint demo was great. Everything was clearly explained in the given amount of time.
2.The requirements and designs matched perfectly. We didn’t need to go around asking questions
3.We are getting better at running the daily standups. I think we are getting relevant updates without getting sidetracked
4.The release notes for the last sprint were top notch. Some complex updates were described in an easy to understand manner
What Didn’t Go Well
What’s slowing us down and creating hurdles in our work? Things that the team needs to hear about and help solve. Some examples are:
1.Too many disruptions in the sprint for support issues.
2.The QA team is finding too many issues in the tickets that are sent over to them.
3.Need to balance the UX with technical feasibility when creating requirements. Some things that seemed like a small UX change turned out to be massive.
4.We were short staffed for this sprint and it was not accounted for in the sprint planning. As a result a lot of tickets were not completed.
5.This sprint was all about new features. We still have a lot of bugs and support tickets that need to be resolved. They need to be triaged and brought into the sprint. We need to balance the distribution between new and maintenance work.
The “What went well” exercise is only useful if it ends with concrete action items. The team needs to brainstorm and figure out how to solve the issues identified in the “What didn’t go Well” section. All action items should have:
1.Due Dates: When will the action items be completed? If it’s not possible to estimate it in the meeting then the action item should be a research spike with a due date for that instead.
2.Assigned to: Who will be responsible to complete the action item.
You might end up in a scenario where the due date keeps shifting forward and action items keep piling up with each meeting. This is a big red flag. It means that your retrospective isn’t working and you need to shake things up. In this case you will find the following blog useful:
A fun way to start sprint retrospectives is by using icebreakers. These questions help the group get used to the idea of interacting with each other. It also fizzles out any tension in the room and makes the atmosphere of the meeting cordial. Some examples of agile sprint retrospective meeting are:
1.If you had to give a lecture on one thing, what would it be?
2.If you could meet any historical figure, who would you choose and why?
3.What current fact about your life would most impress your five-year-old self?
4.If your home was packed full of golf balls how would you remove them?
Check out our the full repository of over 300 retrospective questions