“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.