What Went Well
What Went Well Definition
What Went Well is a retrospective technique that serves a crucial role in the agile methodology and has become widely used in the agile community. It is one of the best opportunities for both remote and in-office teams to analyze any potential improvements by asking two (seemingly simple) questions: what went well and what didn’t go so well?
One of the most important benefits of this retrospective method is that it helps team members analyze the whole process from the previous sprint. They can also brainstorm ways to improve productivity and boost efficiency. Using ‘What Went Well’ is especially great for new teams, helping them stay focused and set action items to develop new improvements before the next sprint or project iteration.
How do you organize What Went Well?
In order to start a What Went Well retrospective, the facilitator in charge should present how the method works. Then, they should tell the team that the total time limit is 30-60 minutes, depending on the size of the team. Before moving further, make sure everyone understands the technique and that they feel comfortable proceeding.
The next step should not take more than 15 minutes, as you ask all participants to answer the questions “What Went Well?” and “What Didn’t Go Well?”. They should write one idea per sticky note and a record should be kept. At this stage, team members should continue to keep their thoughts private, as it is important for everyone to have their own ideas without being influenced by their peers. Once time is up, all members’ notes are organized by which question was being answered.
The third step should take a maximum of 10 minutes — it’s time for theming. Often, the output notes will be similar in topic or theme. So, during this time, all participants should collaborate to group the notes into appropriate buckets. This is done to save time during the next step and ensure all themes are covered.
If the discussion topics are not obvious, the facilitator can opt for a dot-voting session. This way, each participant receives a number of votes they can allocate based on which subject they deem worthy of prioritization.
The next step is to discuss the topics under each question. Depending on team size, anywhere between 20 to 40 minutes should be allocated. If dot-voting wasn’t used, the order of discussion can be chosen by the facilitator. It is important to frame each subject into a timebox so the conversation can move at a faster pace.
During the discussion, all team members need to keep in mind that they have to present the positive side of what went well, but also come up with ways to improve for future sprints. The purpose is not only to learn how to avoid issues next time, but also to do more of what went well!
One of the greatest benefits of this method is that even newcomers can contribute to the discussion. In an agile environment, the team should come back to the What Went Well technique after approximately two weeks to check on their progress.
What Went Well ideas and examples in an agile environment
Part of the What Went Well technique’s beauty is how straightforward it is. That said, there are certain things any team should avoid.
For example, group thinking should not happen at all. The individual’s ideas are much more valuable in this context. This happens rarely, but arguing with your team members should also be avoided! This defeats the purpose of having a fast-paced, open-minded discussion.
So what can you expect from your What Went Well retrospective?
Depending on the project, there can be a multitude of What Went Well examples, such as:
We shipped on time with no bugs reported.
The collaboration was great in our paired coding sessions.
User testing was better developed this sprint.
The team had a good time working together.
All members knew what they had to do — and did it!
On the other hand, here are some What Didn’t Go Well examples:
There were unclear responsibilities and roles in the team.
Bottlenecks appeared.
Priorities were not clear and members did not take them into account.
We had to postpone the release date of the product.
User stories changed late in the sprint.
The QA workflow experienced trouble and we had to wait a long time for a review.
When to use What Went Well
What Went Well is best used by teams using agile product workflows. As a reflective exercise, it lends itself perfectly to sprint retrospectives. The What Went Well framework can also lend itself to various situations, even outside of product management!
The What Went Well framework helps us review our work with little to no emotional bias entering the conversation. It simply focuses on objective outcomes that can be measured to demonstrate success. This is vital during retrospectives as the conversation needs to focus on tangible wins and losses during development.
If your team opts to bypass sprint retrospectives and simply hold a post-mortem retrospective at the end of the project, the What Went Well framework is essential to ensure you learn as much as you can from the project.
Finally, the What Went Well framework can be used as a lightweight retrospective. This is useful for busy teams or when a project is falling behind schedule. It gets down to brass tacks and identifies whatever issues are holding the team back.
Pros and Cons of What Went Well
Pros:
The What Went Well framework offers product teams a vast range of benefits when running an informative retrospective. Here are just a few:
Focusing on positive outcomes can help build momentum and enthusiasm for future projects.
It can help identify best practices and success factors that can be replicated in future work.
Celebrating wins can help boost team morale and foster a positive team culture.
It is a simple and easy exercise to conduct, requiring minimal preparation or resources.
Cons:
As with any retrospective exercise, it is important to know the potential biases or blind spots that may arise and to encourage an open and constructive environment for sharing feedback and insights. Here are a few cons with What Went Well:
Groupthink can be a potential issue, where team members may feel uncomfortable sharing their individual experiences or perspectives.
People may not agree on what went well, leading to disagreements or frustration.
Focusing exclusively on positive outcomes may overlook valuable learning opportunities and blind spots in the team's performance.
The exercise can become repetitive or superficial if not conducted with clear goals or specific outcomes in mind.
Template for using What Went Well
The What Went Well framework is traditionally made up of three sections. However, we recommend adding an extra section that allows for questions from the team. This additional section will ensure everyone walks away from the conversation with complete clarity for future projects.
Here’s what your What Went Well session should look like:
Step 1: What went well
Describe the positive outcomes, achievements, or progress made during the project or period.
Provide specific examples and quantify the results if possible.
Explain why these things went well and how they contributed to success.
Step 2: What didn't go well
Identify the challenges, setbacks, or failures encountered during the project or period.
Provide specific examples and describe the impact of these issues.
Explain why these things didn't go well and what could have been done differently to avoid or mitigate them.
Step 3: What to improve
Based on the successes and challenges identified above, list the areas that could be improved or optimized in future projects or periods.
Provide specific recommendations and actionable steps for addressing these areas.
Explain how these improvements could contribute to better outcomes and results.
Step 4: Questions we have
List any outstanding questions or uncertainties that must be addressed before moving forward.
Explain why these questions are essential and what information or actions are needed to resolve them.
General FAQ
Experience the new way of doing product management
