Retrospective and Futurespective Techniques

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” — Norm Kerth

Retrospective Overview

Retrospectives should not be a forum to gripe, blame, shame or otherwise generally complain with no action. The key ingredient to any technique is walking into a retrospective knowing that every person did the best they could with the information and tools they had. The goal is to learn and identify the areas to improve information, tools, and safety through cooperation and sharing as a team. Once we work as a team, we become more effective and successful.

  • Value Definition: Retrospectives deliver many benefits: They give power to teams, enable teams to do their own actions and to do sustainable improvement.

Below are some different methods to Set the Stage, Generate Ideas, Generate Insights, Decision Helpers, and Closing a Retrospective

Setting The Stage

Often before larger retrospectives, it is a good opportunity to check the safety level of the team. Engineering Safety involves preventing and/or breaking a cycle of mistrust. Removing negative assumptions and self-protective behavior is critical. Cycles of mistrust start from poor communication, negative assumptions, and lack of shared understanding. Doing a ‘temperature’ check, particularly before sensitive retros, can help you understand the level of mistrust. When safety is low, feedback is minimal if given. So doing a few checks can help improve the safety relatively quickly.


Create a quadrant with areas for E, S, V, P.

  • Explorer: Eager to dive in and research what did and didn’t work and how to improve.
  • Shopper: Positive attitude. Happy if one good things comes out.
  • Vacationer: Reluctant to actively take part but the retro beats the regular work.
  • Prisoner: Only attend because they (feel they) must.

Take an anonymous poll (I use post-its) and count the answers. Place the post-its in the quadrant to help visually see if the safety is low or high. If safety is low, destroy all the votes afterwards to ensure privacy. Ask for feedback on the data that was collected. If you have a ton of Vacationers or Prisoners, Id focus the retro to discuss that. Nothing will be more important to discuss, no status update or progress check will be more important than digging into why the trust level is low on the team.

Weather Report

Using drawings of different types of weather, or use the words in columns for ‘rain’, ‘thunder’, ‘sunshine’, and ‘clouds’. Have the team put a sticky note on how they felt the sprint went. You can do this anonymously and have it indicated if you have low safety. If the weather is bad, focus on driving what action items could be taken to immediately improve the sprint/retro focus.

Emoticon Project Gauge

Help team members express their feelings about a project and address root causes early. Prepare a flipchart, notecards, or stickies (or digital equivalent) with faces expressing various emotions such as:

  • shocked / surprised
  • nervous / stressed
  • unempowered / constrained
  • confused
  • happy
  • mad
  • overwhelmed

Let each team member choose how they feel about the project. This is a fun and effective way to surface problems early.

Outcome Expectations

Everyone on the team states their goal for this meeting. Ideally, what they want out of the meeting. Examples of what participants might say:

  • I’m happy if we get 1 good action item
  • I want to talk about our argument about unit tests and agree on how we’ll do it in the future
  • I’ll consider this retro a success, if we come up with a plan to tidy up that thing we ship

If someone doesn’t know what they want from the meeting, they are free to leave it with the support to do so.

If the meeting is off topic and or lulls, the organizer should ask ‘Are we in alignment with the goals’. Each attendee says they are a number from 1 to 10, where he or she is in getting their what they want or their goal. Lowest score leads the meeting. 10s have an option to leave.

  1. Have a measurable, desired outcome for your meeting
  2. hold everyone accountable for getting their goal
  3. pursue only one ‘want’ or goal at a time

Coffee Talk

Lean Coffee is a technique that helps teams arrive at consensus quickly on topics they would like to discuss. It is also easy to set up and facilitate. The only prerequisites that are needed:

  • People interested in sharing knowledge or evaluating options
  • A workspace, which can be:
    • For collocated participants - An open setting with a tabletop and some chairs (and yes, as you might imagine, a coffee shop is a great choice, as is a conference room)
    • For distributed participants - Quiet locations where networked, handheld devices or computers are available, along with collaboration software
  • A means of writing down/displaying topics to be discussed
  • A method of keeping time (phone, buzzer, stopwatch, etc.)

Number of Players: Works best with groups of ten or less. How to Play:

  • Set up a personal Kanban consisting of a few columns (such as “To Do,” “Doing,” and “Done;” or “To Discuss,” “Discussing,” “Discussed”).
  • Ask participants to write down/display any topics they wish to discuss.
  • Vote on which topics to discuss first, and revote as necessary to break ties or further prioritize topics for discussion as the session continues.
  • Discuss the topics in the order in which the votes dictate, being sure to set a time limit (timebox) for each topic. Participants can also vote on whether to continue the discussion on the current topic or to move on to the next topic.
  • Move the topics across the personal Kanban to indicate whether they are awaiting discussion, are being discussed, or have already been discussed.

One of the most appealing aspects of Lean Coffee is the extent to which it empowers the participants by providing a framework that helps them rapidly frame the direction of the discussions. In lieu of someone else determining the agenda, the team gets to make that decision. Participants can determine how much or how little they participate in each topic being discussed. In addition, participants are free to come and go as they please.

What to do if Safety Is Low

If Safety is high, theres nothing you can do but move forward and progress. When safety is low, its important to take the time to figure out how to improve it. Low safety has a serious impact on any retrospective and will skew any result.

Many people don’t want to share the score so they can run the meeting accordingly. This also helps respect the anonymity of everyones results. The drawback is that only the facilitator then knows the safety is low. People can feel isolated, not represented, and may not recover. You would have to deal with the individual at this point and not the team. I prefer more transparency and encourage it. If there are low scores, ask the team collectively what they think will change it.

One thing you can do immediately is explain the purpose of the retrospective and reassure the team that everything stays in the room with the team. Remind the team the retrospective is to learn so we start with the assumption everyone did the best job possible during the sprint.

If its one bad score, there is not much you can do as a facilitator. Since it should be anonymous, there’s little you can do to help the one person. I would just be considerate that one person does not feel safe and look for signs to avoid certain topics.

You can do some of the below exercises to improve safety. Once you are finished, recheck the level of safety and see if there is improvement. If not, often just focusing on Team Kudos and how they received help from each other and change the course of the retrospective and improve the safety.

Never ignore low engineering safety levels, regardless if they are made clear. If someone is silent, try to involve them. If you get the feeling that someone isn’t open or honest, state that there is still low safety and work to resolve it.

Generating Safety

Think It Then Ink It

Think about what you already know about a given topic. On an index form or other easy-to-share form of media, write down three facts about the topic. Share what you’ve written down with other people in your group/your team. Put all of the observations in the middle of a table or tape them on a wall. Identify any discrepancies among “facts.”

Making Toast

Game Goals:

  • Introduce participants to the concepts of visual thinking, working memory, mental models and/or systems thinking
  • Serve as a warm-up exercise to get people engaged with each other and thinking visually
  • Have fun!

How to Play:

  • Preparation. Ideally you should have Sharpies, sticky notes or index cards, and tape (if using index cards).
  • Hand out the materials to all of the participants.
  • Ask each participant to draw how to make toast; give them several minutes. (It is important to avoid being overly prescriptive in terms of what they draw or how they should draw)
  • Have each participant hold up what they drew.
  • Have the entire group place their drawings on a large wall or table space and facilitate a conversation about the drawings, looking for similarities and differences, such as how many are simple vs. complex; how many show people, etc.

Outcomes: Depending on your reasons for facilitating this game, you might want to point out things like this:

  • Observe that although the drawings are different, they are fundamentally correct. That is, there are many ways to visualize information and they all enrich understanding rather than being “right” or “wrong.”
  • Observe that although the drawings are different in content, they tend to be similar in structure. Based on this and similar activities, people who draw mental models tend to depict from three to seven elements, connected by lines or arrows.

Squiggle Birds

Overview: Squiggle birds is a simple way to encourage people to exercise their visual thinking muscles. What this game illustrates particularly well is that our minds are pattern-making machines, and that we can effectively convey an idea with minimalistic drawings (the mind fills in the rest). How to Play:

  • Provide participants with drawing materials (preferably sharpies and sticky notes or index cards). For remote participants, ask them to use any materials they have available, and send a digital picture either real-time or after the fact.
  • Start by asking participants to draw squiggly lines. They can draw any shape they like, and have them continue to draw several separate, distinct squiggly lines.
  • Ask each person to pick any one of the squiggly lines they just drew, and to add a few basic elements to it that will make it look like a bird (a beak, a couple of spindly legs, and a simple tail).
  • Ask each person to add those same basic bird elements to the rest of the squiggly lines that they drew.
  • Facilitate a conversation about how even the simplest of drawings can effectively communicate an idea.

Fire Extinguisher

  1. Ask for insights on what could be bringing the safety down. You can ask with a question like ‘Put yourself in the shoes of someone who may not be feeling safe, what could be the causes? Write it down on a post it and place it on the board’
  2. Create an affinity group for the cause
  3. ask the participant for ideas on how to improve it. ‘How could you overcome these causes on the board? Place the answer on a different color post-it and place it next to the problems’.
  4. Read the notes and have a guided conversation on them.
  5. Re-Run the Safety Check

Writing the Unspeakable

Do you suspect that unspoken issues may be driving down safety? Consider a silent activity, where you first stress confidentiality (‘What happens in Vegas stays in Vegas’), including stating that all notes from this activity will be destroyed. Ask each participant to write down the biggest unspoken taboo in the company. When everyone’s done, they pass what they wrote to the person on their left. The person on the left silently reads and may silently write comments. Keep passing until each item is back with the person who first wrote it. After everyone reads all the comments, the pages are collected and destroyed.

Generating Data


Draw a speedboat onto a flip chart paper. Give it a strong motor as well as a heavy anchor. Team members silently write on sticky notes what propelled the team forward and what kept it in place. One idea per note. Post the stickies motor and anchor respectively. Read out each one and discuss how you can increase the motor and cut ⚓️

ValueStream Mapping

Ask the team to draw a value stream map of the process they follow from start to finish to complete a single user story. If necessary, ask them to break into small groups, and facilitate the process if they need it. Look at the finished map. Where are long delays, choke points and bottlenecks? Unfamiliar with ValueStream Mapping? Here’s a Video

Sprint Log

Based on the sprint that just ended or whatever subject/release you are discussing, have each team member silently write down their answer to one or more of the following questions:

  • If you were a reporter and were asked to summarize key events that occurred during the sprint/project/release, what would you choose to emphasize? Write a very brief article consisting of a few sentences or paragraphs.
  • What do you know now that you did not know when the sprint/project/release started?
  • How would you summarize your experiences during the sprint/project/release that just ended, if you were speaking with a young child?

Generating Insights

Original Retrospective Four

From Norm Kerth, Use the following four questions to focus your team on.

  • What did we do well, that if we didn’t discuss we might forget?
  • What did we learn?
  • What should we do differently next time?
  • What still puzzles us?

Granting Wishes

Ask the team to silently ponder the following question:

  1. ‘A fairy grants you a wish that will fix your biggest problem at work overnight. What do you wish for?’
  2. ‘You come to work the next morning with the wish granted, How do you know? What is different now?’

If you feel that the team feels safe in sharing these observations openly, discuss the team’s observations. Alternatively, ask the team members to keep their answers in mind without verbalizing them as you move on to decide what to do during the next sprint.

FLAP Process

  1. Prepare and explain the FLAP canvas quadrants:
  2. Future Considerations: Things that we’ll need to think about/focus on next sprint or in the not-too-distant future.
  3. Lessons Learned: Key takeaways from the sprint that just ended.
  4. Accomplishments: Things we finished during the last sprint that we’re particularly proud of.
  5. Problem Areas: This that did not go as well as we had hoped during the sprint that just ended.

  6. Ask the team members to write down their observations, ideally at least one observation for each quadrant. (Optional: Consider color coding the observations to indicate a category. For instance, you could a different color for each of the following:
  • Process and practices
  • Technology and tools
  • Scope and schedule
  • People and staffing
  1. Ask the team members to place their observations on post-its in the appropriate quadrants, then discuss as a group.

Break Up Letter

Borrowed from the Smart Design community, this helps people with emotional connections they have to products, services, and experiences. In this context, you should place emphasis on processes and experiences. This can help people who may have gotten in a rut with retrospectives and need a mixup. As people to write a ‘breakup letter’ to a particular process or practice that has been determined to no longer add value. You can also flip this and write a love letter

Box of Insights

Using a virtual representation of a box (or a physical box), suppose that all of the things we’ve done in a team context over the last couple of sprints are inside of this box. Let’s take a look at what’s inside the box. At this point, list examples of the types of work that was done during the sprint. Based on the list of things we just came up with, and thinking more broadly about any other team or teams we may be on, let’s unpack the box and decide:

  • Take Out. Which things should we remove from the box, i.e., not do them again?
  • Leave In. Which things should we leave in the box, so that we continue doing them?
  • Put In. Which things should we add to the box, i.e., start doing them?

Generate Action

Pose a central question for the team members to answer, such as ‘What actions should we take in the next sprint to improve?’. Ask each team member to silently write their answer to the question. After about 3 minutes, ask each person to pass what they wrote to the person on their left. Have them read what their neighbor wrote, and either add a completely separate entry or extend on the original idea. Continue to pass and repeat the same process until each person has what they originally wrote in hand. Have each person read all of the entries, discuss as a group, and use a prioritization technique to decide which things to focus on during the next sprint.

Decision Games and Techniques

Dot Voting

Draw an area with three sections, with the headings Start, Stop, and Continue. At this point you can either leverage conversations you have had from earlier in the retrospective, or you can set aside a block of time for team members to write silently. Ask the team to arrange their notes into the appropriate categories. Facilitate a conversation about what is in each category. Use “dot voting,” where each person gets three votes, represented by dots or if you are remote, add a ✅ on the items they think are most important to focus on during the next sprint. Votes can all be cast on a single item, or the can be distributed across multiple items.

Action Caption

  1. Start by drawing a large 2×2 matrix with a square labeled “Actions” in the middle; this is designated for the changes that the team commits to making as a result of the retrospective. The four quadrants surrounding it represent different aspects of your retrospectives:
    • Puzzles: Questions for which you have no answer
    • Risks: Future pitfalls that can endanger the event
    • Appreciations: What you liked during the previous iteration
    • Wishes: Not improvements, but ideas of your ideal event
  2. Provide the players with pens and sticky notes, preferably different colored notes for each quadrant. Have the participants write their ideas for “Appreciations,” “Puzzles,” “Risks,” and “Wishes” one category at a time.
  3. Once players have written all their thoughts, ask them to post their notes on the chart. As a team, go through the ideas and cluster related ones together.
  4. Discuss the novelty, feasibility, and impact of the ideas, and collaborate to analyze how they can be applied to the next event. Use this process to create practical, efficient “Actions” in the middle.

All Thumbs

Thumbs is the easiest of all of the games when it comes to checking for consensus. Number of Players: This technique works well with teams of any size.

How to Play: To use this technique, the facilitator polls the group on a particular topic and asks them to indicate where they stand, such that: Thumbs Up: I strongly support this idea. (kind of side thumb emoji) Thumbs to the Side: I can “live with” this idea. While it may not meet all of my needs, I don’t have strong reservations. Thumbs Down: I cannot live with this idea and have concerns that must be heard by the group before we move forward. If there are no thumbs down, this is a reasonably strong indicator that the team is comfortable with moving forward. However, before doing so, make sure you understand what motivated anyone with a Thumbs to the Side vote to feel lukewarm about the idea.

Closing the Retrospective

Take it Back

Everyone writes a note with the most remarkable thing they learned during the retro. Put the notes in a visible place. In turn each participant reads out their own note.


The purpose of SaMoLo (Same of, More of, Less of) is to ask the team for feedback on how you’re doing as a facilitator. Create a matrix with three columns, with the headings Same of, More of, Less of. Ask each team member to write individual notes to give you feedback (you can stay in the room and talk about it as a group when everyone is done, or you can leave the room and come back when they’re done, or ask them to provide the feedback offline, if you prefer).

Note To Self

While retrospective activities generally focus on the entire team, this activity gives participants an opportunity to think about a specific take-away from the retrospective that they want to be sure they think about. Steps:

  • Give the participants one minute to reflect upon the discussion that has just ended.
  • Have each person write a note to self about something he/she wants to keep in a visible place as a reminder for the next week

    Do You Have Good Follow Through?

Draw a scale, labeled ‘Probability we’ll implement our action items’. Mark ‘0%’ on the left and ‘100%’ on the right. Ask everyone to draw an emoticon of their current mood. Ask everyone to place their emoticon on the scale, to indicate their confidence that there will be follow through on the action items. Discuss what the results indicate.

Futurespective Overview

From time to time, it can be helpful to flip the script, and rather than thinking back on what occurred over the most recent sprint or iteration, instead to take a forward-thinking approach. This type of activity can be particularly helpful if the team has plans to conduct (or already has conducted) a visioning or chartering activity. Similar to a Retrospective, Futurespectives can help teams reach their goals and agree how they will get there.

Futurespective Prime Directive

Much as their is a prime directive for retrospectives in general, consider this prime directive, written with a forward-thinking mindset:

“Hope and confidence come from proper involvement and a willingness to predict the unpredictable. We will fully engage on this opportunity to unite around an inclusive vision, and join hands in constructing a shared future.”– Paulo Caroli and TC Caetano

If you find yourself in a situation where you are working with a newly-formed team, or with a team (whether new or not) that is about to work on a feature set that is relatively unfamiliar, Likelihood vs Impact is a technique that you might find helpful. Given that this is a forward-leaning technique, it is best suited for a “futurespective” conversation.

Likelihood vs Impact

How to Facilitate Consider framing the conversation something like this: As we prepare to start working on <summary of feature set or problem space>, let’s talk about some things that could potentially happen (however unlikely they might be) and how any those things could impact our ability to deliver. To start the activity, ask the team members to either silently write down or verbally express examples of things that could potentially occur that could could slow or stop progress in a particular area in which the team needs to deliver. Set a specific timebox for this part of the conversation, ideally no more than five to ten minutes. Examples of areas that could help generate ideas for this conversation include:

  • Dependencies (e.g., on internal teams, vendors, or funding)
  • Technical issues (e.g., End of Life of a particular platform or software product, challenges associated with software licensing)
  • Organizational dynamics (e.g., a potential restructuring or shake-up in a department or organization, the departure of a key individual)
  • Compliance concerns (e.g., the need to pass a financial or security audit)

Once you have an initial list of items, ask the team to score each one in terms of Likelihood and Impact, where 1 is the lowest and 5 is the highest. When you are done, each item will have an “L score” (relative Likelihood of it occurring) and an “I score” (relative impact if it occurs). For example, you could end up with items scored such as this:

  • L1, I1. Low Likelihood, Low Impact
  • L1, I5. Low Likelihood, High Impact

Managing Outcomes

Once you’ve assigned your scores, you will have many options in terms of what to do with this data. For instance, you could:

  • Arrange the items out in a matrix, with the Likelihood on one axis, and the Impact on the other axis
  • Assign Action Items or next steps (as you would in a retrospective context, for instance)

Defining Nirvana

For the purposes of this activity, choose a time frame – for instance, the next 3 months, or the next six months. Ask each participant to:

  • Write a sentence (or more, if so inclined) to describe what “nirvana” looks like for this team
  • Have each person read their sentence to the rest of the group.
  • Try to come up with a single statement (or possibly more than one) that reasonably summarizes the team nirvana state

I Have a Dream

  • Draw a vertical line, with one side labeled “Hopes” and the other side labeled “Concerns”
  • Ask the participants to write down their hopes and concerns for the sprint that is about to begin
  • Discuss visible patterns in either categories

Definition of Done

Definition of ‘Done’ can be different for different teams and may be called ‘Acceptance Criteria’. Having this criteria is a contract that limits misunderstanding and conflict between the customer and the team. They can limit the rework of a feature once it has been accepted and can guide discussion, estimation, and design. The DoD is not a shared understanding but explicit.

There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release. Either the team does not have the skillset to incorporate activities, the right set of tools, or sprints are actual waterfalls.

Definition of Done is not static and shouldn’t be treated that way. It changes over time as the organization does. Defining one is up to you but don’t assert the functionality of a feature, focus on the value-add of the story. DoD is informed by reality where it captures the activities that can be realistically committed by the team to be completed.


  1. Code is peer-reviewed
  2. Code is deployed to test environment
  3. Feature is tested against acceptance criteria
  4. Feature passes regression testing
  5. Feature passes smoke test
  6. Feature is documented
  7. Feature ok-ed by Product Owner
Written on July 5, 2017