“The What/So What/Now What”

by Jeremy Jarell

Meet the “The What/So What/Now What” Retrospective Format

The “What/So What/Now What” retrospective format is a variation on the classic “What’s Working/What’s Not Working/What to Try Next” theme that many Scrum teams are already familiar with.

But rather than forcing the team to place each item into one of three buckets, this format treats each bucket as a state that the item must flow through to resolution. Not only does this avoid the headache of trying to decide where some items “fit”, but it also makes retrospective items feel more like story items moving across a Scrum board which can make the process feel more natural as it guides the team towards a resolution.

What can you expect to get out of this exercise?

As an outcome of this exercise, you should expect to see the team deal with action items that are more closely tied to issues that arose in the sprint. This is because each action item, which appears in the “Now What” column, will be derived directly from a retrospective item.

You should also expect this format to excel at bringing to light small problems that would otherwise go unnoticed. These small points of friction that aren’t typically large enough to remember during a classic retrospective are more easily captured and analyzed using this format.

When would you use this exercise?

This format is a bit more advanced than the classic retrospective format so wait to introduce it until the team has had several successful retrospectives using the “What’s Working/What’s Not/What to Try Next” format. This way you can be sure that the team is getting comfortable with the idea of introspection and addressing items before switching up the underlying format.

There are also a few symptoms that can tell you if you’re ready for this new format. For example, you may notice that the team is struggling to remember items during the retrospective even though you’ve witnessed many small pain points during the sprint. This can happen because the team has already addressed the larger and more obvious items and has simply learned to live with the smaller items.

Another symptom may be that many of the items the team is bringing up have started to resemble “observations” rather than true pain points. These are items that don’t fit neatly into a “What’s Working” or “What’s Not Working” bucket but still need to be discussed.

If you notice that your team is starting to struggle to fit items into one of these buckets, then this may be a sign that they’ve outgrown the classic format.

How to do it?

Completing this retrospective consists of a few different parts, some of which consist of gathering information while others consist of analyzing that information.

Gather the Information

The goal of this retrospective is to discuss observations that are causing friction for the team but are too small to be called out during a classic retrospective. To this end, the Retrospective Wall is a great tool for gathering this information.


Retrospective Wall

To create a Retrospective Wall first carve off a section of wall or whiteboard in the team space and place sticky notes and markers nearby. Then, each time a team member notices something that they want to discuss during the retrospective encourage them to write the observation down on a sticky note and add it to the wall.

These observations may be things they’ve noticed that are creating friction, something that doesn’t seem to working as well as it could be, or even a good thing that they don’t want to forget to celebrate. Whatever the reason, adding it to the Retrospective Wall keeps the team from forgetting about it.

If you’ve encouraged your team to place items on the wall as they notice them—and even added a few yourself to lead by example—by the time your next retrospective rolls around you should have a great selection of topics to kick things off.

Dot Voting

<If you find you have too many items to get through in a single retrospective, try Dot Voting to narrow down the topics to the ones your team is most concerned with.>

Analyze it

Once you’ve selected the items that you want to talk about move them to the “What” column. Then, starting with the top item, begin discussing each one. If possible, provide examples from the most recent sprint to help jog the team’s memory and to provide context.

Next, move the item to the “So What” column. Here you can discuss the effect that the item had on the sprint and the team. For example, what happened as a result of the issue…or what didn’t. And, most importantly, what did this mean to the team?

Finally, move the item to the “Now What’ column to brainstorm things that can be done about it. This may include catching the issue before it occurs or just responding to it if it’s outside of the team’s control


Note that you’re not committing to action items at this point—that will come later—so feel free to brainstorm as many ways possible to handle the issue. Also know that some items that are purely observational won’t have “Now What’s”, but that’s ok. If those items don’t fit in this column don’t force them…just leave them in the “So What” column.

Creating Action Items

By this point in the retrospective you should have a pretty good feel for which items are the most important. Hopefully, you’ll also have a good starting point for action items for each high priority item.

Although you may have uncovered a wealth of issues, resist the urge to fix them all. Instead, choose no more than 1 to 2 action items from the “Now What” column to address during the next sprint. This can ensure that your team can truly focus on those items and improve your chances of resolving them.

Some items that you want to tackle in the “Now What” column may just leap to the forefront. But, if you have a lot of candidates from this column with no clear winner, feel free to use another round of Dot Voting to help your team zero in on what matters the most to them.

To improve your odds of fixing the underlying issue make sure that your action items are specific. Don’t accept simply “get better at x” and instead demand specific steps of how the team will try to improve the issue. If possible, even ask the team to define metrics that will help them understand when they’ve met their goal. These may be clear metrics that actually measure an improvement or simply an observable end result that the team should see. Either way, defining the end state should help make it clear to the team how they’ll get there.

What to Do with Survivors

Once your team gets comfortable with the Retrospective Wall you’ll find that you’ll often have more discussion items than you can get to during a single retrospective session. If you’re lucky enough to encounter this situation then here are some ideas to help you handle it.

Timebox the Retrospective

Don’t let the retrospective run indefinitely to address all items and don’t try to fit all items in a single session. Creating scarcity around the number of issues that you’ll be able to discuss forces the team to prioritize those issues that are most important to them. In addition, if you let the session run indefinitely then you’ll likely find that the quality of conversation around the later items will be low and unproductive.

Cull the Wall

Don’t leave items that don’t make that retrospective session on the wall indefinitely. This can create clutter and too many items already on the wall will discourage the team from adding new ones. Also, many of those items will grow stale and become no longer relevant by the time they’re finally brought up. Don’t worry, if any of the items you have culled are truly important then they’ll be brought up again.

Promoting the Survivors



In the past I’ve sometimes implemented a “survivor policy” with teams who are new to this format. This means that items that don’t make their initial retrospective can “survive” on the wall until the next retrospective. If you decide to do this, make sure that you visually call these items out either by switching the color of retrospective sticky notes from one sprint to the next or by moving them to a special section of the Retrospective Wall.

Initially, this can help ease fears that simply dropping these items will result in problems never being fixed. However, after the team has had the opportunity to see items survive from generation to generation they tend to notice that those same survivors are rarely chosen for discussion in the next retrospective. This is because the surviving items have either become irrelevant or are simply not as important as those items that have been added since. If you find yourself in this situation then this can be a good opportunity to suggest that these items aren’t worth keeping and help guide the team to the answer of dropping the items after each session.


Wrapping Up

Combining a Retrospective Wall with the “What/So What/Now What” format is a great next step for teams who are comfortable with the classic format, but have addressed many of their major issues and are starting to run dry on topics.

 Before your retrospective becomes too stale this can be a great tool to freshen it up and start to address some of the issues that are lurking just beneath the surface.

If you’d like to more about my thoughts on retrospectives, or agile in general, you can find me at my website www.jeremyjarrell.com, or on Twitter at @jeremyjarrell.

About Jeremy

Jeremy Jarrell is an agile coach an author who helps teams get better at doing what they love. He is heavily involved in the technology community, both as a highly rated speaker as well as a syndicated author whose articles and videos have appeared in numerous respected industry publications.

Picture credits to: Jeremy Jarell and Agile Portugal 

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 Days FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us on the format of Guest Blogging please contact us: info@oikosofy.com.

“Drawing a smiley: acceptance criteria”

by Raquel Pérez

In this exercise we will work the need of asking questions to the Product Owner. The main aim is to define every user story as clear and complete as possible before starting working on it. At the end, we will analyse the acceptance criteria.

What can you expect to get out of this exercise?

Thanks to this exercise we may expect that the team will check the user stories carefully, analyse the acceptance criteria and detect requirements; these requirements could be from an environment to some images or other needs to get the user story complete and not being blocked in the way. One of the key points is the timing, we have to be used to analysing the user stories not before starting developing them but before compromising to develop them in the current spring; ideally during the grooming meeting.

This exercise is looking for encouraging the dialogue around the team.

When would you use this exercise?

This exercise is quite useful when you have recently started working within the scrum framework and your team is not used to think about acceptance criteria; what the user story implies, what boundaries should be set, think about possible blockers/requirements for the development and other questions that may arise from the Product Owner; he is the one who knows what generates the business value.

The main aim is to be as focused as possible during the development time as well as to ensure that what we are developing is the expected! Let’s answer every questions before starting. For that we need a deep understanding about what a user story implies.

How to do it?

This exercise is pretty easy to be implemented.

What do you need? You need, at least, 2 post-its and a pencil for each team member.

Where to do it? You just need the team to be sat down and ready to draw.

How to start? Ask the team to “Draw a smiley on their post-its” and give them 1 minute.

We assume that the team has not asked any questions about your expectations from these smileys. If they ask you questions, you can of course answer them. Then, you will have to adapt the exercise. I’d suggest checking whether every acceptance criteria are taken into account (see example of use story below), if not all of them are asked, just keep the exercise going, if they were all asked, add a new acceptance criteria! I give you an example at the end of the post.

Afterwards, ask team members to show their drawings. After everyone shows their artwork, you can ask them following: “Hadn’t I told you that I expected…” where “…” it is something that someone has included on their drawings, such as for example: You expected the smiley to have square eyes instead of circle eyes or you expected the smiley not to have hair.

Then, you ask them to iterate: Let´s draw a new version, the version no. 2 of their smiley; give them another minute. Feel free to answer any questions that may arise. The ideal situation would be when they ask you questions about expectation. There could be some questions related to smiley’s shape or shape of the eyes.

After a minute,  take a look at the version 2 artwork and check whether they met your expectations.

At the end, you will define the complete user story for this exercise; an example could be:

“As a (´smiley´) Product Owner I want (smiley) ´This particular drawing´ so that I can decorate my wall”

Screen Shot 2015-06-01 at 2.42.30 PM


  • The head is a circle
  • The eyes are oval
  • The smile is curve down”

Conclusions: As a conclusion of this exercise we may point out the importance of asking before doing. In this case, the “waste” has been just 2 post-its and 10 minutes, however, on our daily basis the development of something that it is not expected would mean the rejection from the Product Owner, meaning this needs to change/be updated. We want to avoid working twice!

Rachel is a certified Scrum Master based in Spain. She is passionate about Agile and Scrum methodologies and enjoy working within a team environment.

If you have any questions related to this article, feel free to contact Rachel on Twitter @rachelLondoner.

Picture credits to: Rachel Pérez

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 Days FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us on the format of Guest Blogging please contact us: info@oikosofy.com.

The Mutant Star Fish

by Stefano Porro

The mutant Star Fish is my personal customization of the famous retrospective exercise called Star Fish. It adds to the typical three questions of the original exercise: What Went Well? What did not go so well? What should be improved? Another question focused on the team: “Why is important to me work in this team?”

What you can expect to get out of this exercise?

This exercise helps, like the original one, to identify problems and opportunities for the team using a simple visualization method. And moreover it permits you to identify the individual needs of the team members. While the original exercise focusses (correctly) on the team, this customization helps the team to also understand the individual needs.

Typically, we have five sections

1. Stop: In this section, team will bring the activities that don’t bring any value – waste

2. Less: Here team will bring the activities needed to be reduced because they require a high effort but don’t bring as much value as they expect

3. Keep: Activities that the team wants to keep and already performed. These are activities where effort and value produced are balanced

4. More: Activities not so often performed but very valuable. The team could decide to adopt these activities more often to boost their performance

5. Start: new activities decided by the team to bring more value. We can say these activities are experiments.

Now we add another section and we can call it as we want: WII-FM (What Is In For Me), Coolness, Amazing. Name this section with a word (or a little sentence) that can help the team members to understand that this section is made to gather their individual sentiments and needs. Because we are working as a team, and a team is made by individuals!

When you would use this exercise?

I suggest to use this exercise with teams that are new to Scrum (or Agile, generally). When people are new to Scrum, they are looking for their motivation. Focusing the exercise to both team performance and individual needs can help them to create a climate of “self-motivation”. They will understand that we are working as a team but we will never forget the single persons in the team. When a team starts with Scrum, team members are looking for a motivation to start this journey. In this way we ask them for it explicitly.

How to do it?

First of all draw a picture like this:



I’m sure you all know how to use this schema (except the new section).

Anyway, let’s see quickly how to use this retrospective exercise.
Ask the team to use about three minutes to gather, individually, ideas for the STOP section (they will use post-its to dump on the flip-chart). After that, use 10 minutes to make the members read loudly from their post-its and to align all team members, discussing about those ideas.

Repeat the same for the LESS, KEEP and MORE sections.

For the START section ask your team to vote for a single subject. In this way you can make them focused on a single topic, probably the most important to them. So study a strategy with the team so this idea will be well implemented. The strategy is helpful because to know if an implementation is successful, you need success criteria.

Luis Gonçalves says that the order in which you put the sections in the flip-chart is important (as important as the order in which you ask for them) and I totally agree. In addition, I put START and WII-FM in the two bigger sections (at least for an optical illusion) and I underline the words. In this way the team will concentrate more on the positive things. A little bit of psychology.

So, we have gone trough the START and we proceed almost to the closure of the retrospective.

At this point the team would have talked about the team process: now it’s the moment to talk about the individual needs and performance. Ask the team members to write something on post-its in five minutes (give them a little bit more time) and after that ask who will be the first to present his/her post-its.

Team members have to read loudly from their post-its and then explain their meaning briefly. After everyone reads his or her ideas, the Scrum Master will re-analyze all the post-its to understand if all things are clear. The action from these post-its its won’t be implemented for the next sprints, but they’ll give the team the possibility to explain what they are looking for to know about Scrum and the possibility of the Scrum Master to adapt his work in a twofold manner: team performance and individual performance. For example the Scrum Master could identify people who are having problems in the company so he or she can act quickly to avoid transitions.

This exercise, moreover, helps not to lose the focus on WHY we are using Scrum, and this is a very important thing to remember. Developers wouldn´t be so impressed by numerical motivations (ROI, etc.) but you, as a Scrum Master, must find the right key to motivate them. And in this way they’ll help you to discover the key to their success.

About Stefano 

Stefano is from Turin, Italy. He has worked in IT projects since 2001 and he feels lucky because he does what he loves. He learned about Scrum in 2007 when the company where he worked decided to adopt Scrum. For the first two years he was part of a Scrum team. And he was fascinated about the role of the Scrum Master because he always loved to help team members. For him, becoming a Scrum Master, was a natural evolution.

You can find Stefano Porro on Twitter @StefanoBowen and connect with him on Linkedin.If you prefer email, feel free to contact Stefano at stefano.porro81@gmail.com.

You can follow Stefano’s blog http://agilekarma.com/author/stefano-porro/ to know more about his work and his ideas.

Picture credits to: Stefano Porro and Bill Sutton

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us on the format of Guest Blogging please contact us: info@oikosofy.com.

An Energising Retrospective Plan

by Samantha Laing and Karen Greaves

If you have retrospective regularly you will know that they each have a different feel. Some are serious, some are fun, some look far back, some are about other areas and not the team. Occasionally we want to have a retrospective that will leave us energised and super excited to get going on actions. Here is a plan we follow at Growing Agile for an energising retrospective:

Checkin [3 min per person]
We have sticky notes with the following headings: Be Brave, Be Kind, Be Yourself, Be Involved, Be Amazing, Be Accepting. You could make your own or use colours to represent different things.
Each person writes up one statement per sticky note about the past month (or sprint) and then everyone shares what they wrote for each.

Gather Data [15 min]
A variation on the perfection game. We score the month out of 10 (where 10 would be perfect) and each list 3 things  we would have liked to have happened in the last month. Depending how many people are in the retrospective you can reduce the 3 things down, in the next section you don’t want more than 15 in total.

Generate Insights [30 min]
A discussion about the 3 things each person listed, why those would have made the month better. Consider these questions:
“What was lacking and why?”,
“What experiments have we done recently?”,
“What have we done for ourselves recently?”

Decide what to do [30 min]
Look at the list of 3 things each person wrote as missing, and any other data you have on things you’d like to do, maybe an improvement backlog.
Each person picks 1 thing they really want to do next month, and shares it.
Give people an opportunity to give feedback on why you would or would not want to do some of those actions.
Now dot vote to pick the top action.

Once you have a top action, create an action task board by breaking it down into tasks that are small enough they could be done immediately by any one person. This is key to making the action exciting. If you see something you could do straight away you are more likely to get started.

Close [1 min]
Stick up your action task board and get cracking!

This is a guest post by Samantha Laing and Karen Greaves, Agile Coaches at Growing Agile. If you have questions about this exercise, feel free to contact Samantha or Karen on their Twitter@samlaing & @karen_greaves

Picture credits to: Paul Downey

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us on the format of Guest Blogging please contact us: info@oikosofy.com.