Goldilocks Goals: How to keep Retrospectives fresh and engaging

Retrospectives are the lifeblood of a team’s drive for continuous improvement and a force for good on software development projects. Teams should have a Retrospective at the end of every single sprint and they should never, ever cancel a Retrospective.

But how do you keep retrospectives fresh and engaging, when they should be ubiquitous and routine? One way to do this is by varying the activities that comprise the retrospective. Running a Stop/Start/Continue post-up every two weeks is going to get stale really quickly. So, if you don’t vary your retrospective activities at the moment, go invest in a copy of Agile Retrospectives by Derby & Larsen or just google “retrospective activities” and gather some ideas.

Another way to keep Retrospectives fresh is to set explicit goals for each session. Often, these sessions are run with an implicit goal of “Let’s see what we can improve”. I’d argue that running every Retrospective with that goal, implied or otherwise, is a mistake. Instead, facilitators should choose a goal related to what’s important in the team/project/company, right now. Doing this will help guide the team toward a subject that is new, interesting or timely, and is therefore worthy of their investment.

Like the interminable Start/Stop/Continue activity, running every Retrospective with the same goal can be a bit… well, dull. Doing so invites the team to think about things in the same way they always have, with the same perspective and bias. In a Retrospective, we should endeavour to look at events and ideas in a new light, to challenge habitual thinking and to be innovative.

However, just choosing a specific, varying goal for each Retrospective isn’t quite enough. You want to choose a Goldilocks Goal.

You’ve guessed it – a Goldilocks Goal is a goal that is “just right”. Just right in terms of the scope of discussion it opens up during the meeting. A Retrospective’s goal should allow the group to thoroughly explore a decent-sized subject but not opening up an area too big with too many possibilities for a 60 to 90 minute meeting to reasonably cover.

The image below represents the structure of a Retrospective meeting, incorporating the distinct stages of the meeting popularized by Derby & Larsen.

New Framework - No ActionsThe session opens up on the left, starting the discussion and gathering data points (the green circles) within a certain scope. Then comes the central, creative section of the session where data is analysed and people start to think creatively; connecting dots and spotting patterns in order to come up with novel insights. The session should then begin to narrow focus, converging the discussion towards an agreed set of tasks and the closure of the meeting.

The meeting’s goal is what opens up the discussion on the left of the diagram, setting the scope and dimensions of the whole session. If that goal opens up a subject that is too narrow or too wide, then the meeting will be ineffective and misaligned.

Goldilocks GoalLet’s use an example: it’s Retrospective time and your team is still recovering from a sprint where they accidently released the installer for the Spotify desktop client rather than their own software (this, obviously, is an entirely made up scenario). You, as designated Retrospective facilitator, decide to go with the usual goal for the session:

“Find out what we can do better”

This is often the implied goal of a recurring Retrospective. There is a real danger here that the story team’s fail is lost amongst the huge number of subjects that arise from the last sprint – bugs, meeting problems, practices, environment, etc. This very open goal could lead to the team being unable to generate any real insight. They will struggle to tie together a legion of data threads, unevenly explore particular bugbears and lose the focus needed to delve into root causes of the most important issues facing the team. At the end of the session the group will, frequently, be left with some relatively inconsequential actions to progress over the next few weeks.

On the other hand, facilitators can go the other way and choose a goal that is too narrow. Doing this will mean the session only supports debate on a very specific topic, data points will be scarce and the group will lack the shared experience needed to engender a proper brainstorm. In our example, you decide to get straight to the root of the problem (as you see it) and introduce the team to the following Retrospective goal:

“Find out what’s wrong with our automated tests”

This goal could easily result in a session that is predictable and routine, where the group will only be able to talk about automated tests and unable to exert influence on what is explored and tackled. The end result of this session may be concrete actions to improve something that is relatively unimportant when compared to other problems on the project. What if we shipped the Spotify installer because of a manual error? What if that manual error occurred because someone was forced to rush to meet an unreasonable deadline?

A goal that is too closed may mean that some people feel marginalized or demotivated, as they are unable to contribute to the discussion. Furthermore, this is a leading goal. The facilitator has already decided the root cause and preferred solution to the team’s problems. This is not cool, and your Facilitator Hat should be confiscated immediately.

So, instead of choosing a goal that is too open or too closed, facilitators should spend some time defining a Goldilocks Goal that opens the debate up just right. Teams need a goal that is open but has boundaries. That way the debate can be influenced and re-aligned by the team, but the meeting is focussed on a key area and is less likely to head off at an unproductive tangent. The boundaries of the goal could be delineated in a plethora of ways – time, function, process, practice, commercial, technical, etc. The facilitator should use their judgement, or the insight of the team, to find a restricted scope suited to the current situation.

In our example, I would argue that the following goal was just right:

“Decide what we can learn from our last release”

This will focus the session squarely on the main pain point in the sprint but will still allow team members to raise issues that they feel are connected (a team member’s absence or a crazy deadline). It should ensure that there are fewer threads of data to explore and analyse, as the discussion is bounded by the timescale of the release and the components that comprise deployment (tests, automation, people, etc). Actions arising from this session are more likely to be tackling root causes of important issues, and ensure the team improve in a valuable way.

So, to recap… in order to keep your regular Retrospectives fresh, engaging and relevant, vary your activities and set a specific goal for each session. Make sure the goal is a Goldilocks Goal; not too open, not too closed, but just right.

When the going gets tough, don’t cancel the Retro

If times are tough on an agile project, whatever you do, don’t cancel the Retrospective meeting.

Let’s be clear, cancelling that meeting is removing an opportunity for the team to inspect the way they have been working, and adapt how they do things so they can improve.

Stop Start Continue

That’s an opinion I’ve held ever since I started working on agile projects back in 2008. It just seems logical to me. I had a conversation this week that reinforced that position.

I was chatting to a couple of members of a development team over lunch about their project.  They couldn’t really stop themselves from complaining about some difficulties their team had been experiencing over the last few months. They highlighted a few issues that they felt could be improved and discussed how they’d like to change aspects of how they work together. My overall observation was – they seemed pretty fed-up.

When I asked if they felt they could discuss these worries in their next sprint retrospective meeting, one of them told me how those meetings had not really helped solve their problems in the past. In any case, their team felt they spent too much time in meetings in general, so they had decided to change their process and only have retrospectives at the end of every other sprint. As a result, they had a retrospective meeting once a month.

I recommended that they have a retrospective as often as possible, given their description of the project. One of the team members stopped me and said, quite matter-of-factly and without a drop of irony, “Some of us, Chris, have a more pragmatic approach”, he shrugged apologetically, “we just prefer action over meetings”.

He looked at me somewhat condescendingly, eyes filled with pity as he considered my misplaced faith in a meeting. How could a group of people coming together to talk about stuff be preferable to actually ‘doing things’?

Somehow I managed to stop myself from slamming my forehead into the table in disbelief. I also avoided making the suggestion that the pragmatist’s preferred action seemed to be complaining about the problems they had, rather than trying to resolve them. I did, however, embark on a robust cross-examination of what was meant by the term “pragmatic”.

My recommendation to the two colleagues (who are good guys, by the way) was to not give up on retrospectives but to talk to their manager/scrummaster/facilitator to see if they can design a meeting together that would help them tackle their problems. And they should definitely have a retrospective every sprint.

I described the kind of retrospective activities that might help surface and explore the issues they were experiencing. A teamwork satisfaction poll, perhaps? Or a Mad/Sad/Glad activity? This seemed to gain some traction with the other team member, who went away to talk to the facilitator earmarked for their next retro.

Teams can label the time they spend in retrospectives as worthless and futile. Often, this is because they’ve experienced some poorly run or structured meetings that have failed to produce valuable, insightful actions. In these cases, I’d plead with a team not to give-up on retros and suggest reading Agile Retrospectives by Derby & Larsen to give their meetings a better chance of success.

Teams have been know to cancel retrospectives if they feel like they are under too much time pressure and are forever racing to reach difficult deadlines. For me, taking time away from your desks to reflect on what is going on when a project feels like it is in a perpetual race against time, is invaluable. To be honest, if you think that having the team in a meeting room for one hour every two weeks is going to make your project fail, then it’s going to fail anyway.

So, if you are on a difficult project and are considering cancelling or reducing the frequency of your retrospectives, ask yourself what the root cause of that drive is. Then consider whether that root cause is something that would actually benefit from a regular, frequent opportunity to inspect and adapt.

Retrospective Activity: By The Numbers


I thought I’d share a sprint retrospective activity I came up with recently. As I outlined in a previous post, I like to structure the retrospectives I facilitate in the form popularised by Esther Derby and Diana Larsen in their book Agile Retrospectives. That structure has five sections, each with a specific goal:

  • Set the stage – Goal: Set the tone and direction for the retrospective
  • Gather data – Goal: Create a shared memory; highlight pertinent information and events
  • Generate insights – Goal: Think creatively; look for patterns, themes and connections
  • Decide what to do – Goal: Generate and prioritize valuable, clear actions
  • Close – Goal: Summarize and end the meeting

This activity – “By the numbers” – is an activity for the Gather Data stage.

Retro in progress

Retrospective Activity: By The Numbers


This activity is useful for the Gather Data phase of a retrospective, as it encourages team members to focus on cold facts rather than evaluations or opinions (which are for the Generate Insights stage). Like any good retrospective activity, it leaves room for people to influence the path of the meeting by highlighting events and facts that have significance for them.

Time needed

This is a fairly quick activity that you can tailor to be fifteen to thirty minutes long.


The team generate a list of the facts and figures that describe the current state of the project.


1.  Introduce the activity by saying “the aim of this activity is to create an overall picture of the current state of the project objectively, without evaluations or opinions. We’ll do this by calling-out numbers that illustrate where we are. For instance, we currently have X green tests and there are Y developers in the team.”

2.  Give each person a sheet of paper and a pen. Tell them they have three to five minutes (decide which!) to create a list of the numbers they think are significant for the project. Ask them not to look at each other’s paper and tell them that the numbers can be approximate if they can’t remember them precisely.

If the team are struggling to write much down, try a couple of the following prompts:

  • “Think about what has happened to you over the last sprint. What numbers are involved with those events?”
  • “What are this project’s vital statistics?”
  • “How would you describe the project to someone else only using figures?”
  • “What are the ideal numbers for aspects of the project? Now, what are the actual numbers?”

It’s likely team members will choose figures that help them illustrate an issue or achievement that’s on their mind – like “100 ignored unit tests” or “zero open support tickets”. This is great and will provide good food for thought in the next stage of the retrospective.

3.  When the group have finished making their lists, it is time to share. Ask for a volunteer to start the process by calling out one of their significant numbers. They should not divulge what the number pertains to. Write the number on a whiteboard so the team can all see it.

Ask the rest of the group to call-out and guess what the number relates to. The interaction might go something like this:

  • Volunteer: “37”
  • Team member #1: “Is it – the number of users who had a support query this month?”
  • Volunteer: “Nope”
  • Team member #2: “Is it – the number of days since we went to the pub as a team?”
  • Volunteer: “Nope”
  • Etc, Etc..

When someone guesses correctly or the process has taken longer than a minute or so, write what the number was related to up on the whiteboard.

4.  Go around the group in a round-robin fashion, asking people to share one of their significant numbers and the group guessing what they pertain to, until you have filled the whiteboard or the timebox you set for the activity.

5.  Debrief the activity by asking:

  • Are there any patterns in what is significant to us?
  • Are there any surprises there?
  • What numbers would you like to change and what would you change them to?


If the team is stumped when it comes to generating the numbers or are very worried about precision (e.g. “I don’t know how many unit tests we have, off the top of my head”), invite them to go back to the team area in the office to gather data. Make sure you get agreement on a definite time for them to be back in the meeting.

You can also make the activity a group game by breaking the team into two subgroups to come up with the numbers. Then you can make the activity competitive by scoring teams on how many of the opposing team’s numbers they can guess.

To decrease the time needed for the activity, remove the guessing part of the sharing phase – this would be less fun but would gather the same information.

What happened when we tried it?

I’ve run this activity couple of times, most recently today, and it’s worked well. Whenever I’ve used it some team members have taken a little time to warm to the activity, so I’ve needed to reiterate the instructions and encourage them to give it a shot.

Giving examples of the kind of thing you are looking for always helps. Today I gave the following examples, which seemed to unlock the group:

  • 347 people on the our beta mailing list
  • 24 technical debt items on out debt board

After a couple of attempts to guess what other people’s numbers are about, there’s usually good energy in the room. Suggestions can be frivolous and funny or serious and insightful – which is great. By the end, we got a pretty good idea of what people feel is important about the project at the moment.

If you are interested, here’s an image of the whiteboard after we’d done the activity today:

By the numbers

If you give “By the numbers” a go, let me know whether it worked well for you or not!

Five steps to an effective sprint retrospective

In a typical agile software development process, sprint retrospectives are meetings run at the end a development iteration. In those sessions the team looks back on what they have done and how they have done it, and decides what they can do to improve. More succinctly, the team inspect and adapt.

Inspect and Adapt

In my experience, sprint retrospectives are invaluable and the most effective, timely and action-focus form of ‘review’ meeting. If run right, these meetings can be the life-blood of a development team – encouraging them to habitually build on successes and address problems.

However, sprint retrospectives can be tricky to run ‘right’ and as a result, they can be ineffective. An ineffective retrospective might be shallow – only looking at surface issues and not root causes – or it may even forget the adapt part of “inspect and adapt”.

Here are five things you can do to increase the likelihood of running an effective sprint retrospective:

  1. Allocate enough time for the meeting. Book an hour at least, you can always leave early if you have finished
  2. Structure the meeting carefully to ensure the session flows well, from a clear opening through to the definition of actions at the end
  3. Use engaging (and fun, even) activities throughout the session
  4. Vary those activities each retrospective to ensure that these regular meetings stay fresh and challenge attendees to look at things from a new perspective
  5. Be tenacious when it comes to creating a small number of concrete, actionable tasks at the end of the meeting. These actions are the real value of the retrospective – the teams adaptations and the mechanism through which they will improve.

I’d recommend doing all those things, but I’d like to focus on how to structure the meeting.

Below is a retrospective structure popularised by Esther Derby and Diana Larsen in their book Agile Retrospectives. It has five sections, each with a specific goal.

  • Set the stage – Goal: Set the tone and direction for the retrospective
  • Gather data – Goal: Create a shared memory; highlight pertinent information and events
  • Generate insights – Goal: Think creatively; look for patterns, themes and connections
  • Decide what to do – Goal: Generate and prioritize valuable, clear actions
  • Close – Goal: Summarize and end the meeting

For each section of the meeting, you should plan an activity (sometimes something as simple as each person saying one word) that meets the requirements for that section and progresses the team along their mission to “inspect and adapt”.

I like to visualise the meeting like this:

Retrospective structure

Once you become familiar with the stages of the retrospective and what needs to be achieved, it’s fairly easy to come up with new activities (on variations on existing ones) to make your retrospectives feel fresh. As an example, in an upcoming post I’ll outline a quick activity I came up with to gather data in a recent sprint retrospective I ran with my team.

The Art of the Retrospective on InfoQ

Last year I gave a talk about retrospective meetings at Agile Cambridge 2013 – a conference for Agile and Lean practitioners in the East of England. My session was called “The Art of the Retrospective” and was focused squarely on sprint retrospective meetings. The 90-minute presentation (!) tried to answer why these regular meetings are often unpopular with the teams and team leaders they are meant to empower. I followed on with some practical advice on how to structure, focus and facilitate these meetings.

This was the first time I had ever given a talk at a conference, and the the first time I talked to any group for longer than about 30 minutes. Amazingly, despite my inexperience and clearly evident nerves, the session received some really good feedback.

The session was recorded by the good folks at InfoQ and the video was finally published last week.

 The Art of the Retrospective from Agile Cambridge 2013

I was kind of dreading it being published because I knew I’d inevitably make myself watch the session. I was expecting it to be pretty cringe-worthy and after a viewing, I was dead right. However, it was really useful to look back and discover how I came across, what my body language was like (poor, if you are interested) and whether I actually said what I wanted to say. As a result, I hope I can make vast improvements for my next session.

If you can forgive the repeated “ums”, a reticence to GET TO THE POINT at the start and my nervous oscillation between the screen and lectern, I reckon the video contains some decent practical advice for team leaders who want to run effective and engaging sprint retrospectives. So click on the image above to go to the talk if you want to hear about some of that stuff. If you want to go straight to the practical advice, jump in at 22 mins and 30 seconds.

If you have any constructive feedback on the session, please let me know by commenting on this post.

Create tangible retrospective actions

In my view, the drive to inspect and adapt is the most important concept to have been popularized by the agile software development movement.

It’s an idea that got me hugely excited and engaged in the subject when I first came across it in 2005. This essence of this is that ‘we will always know more about the project in the future than we do right now’. The responsible response to that is to build in regular, frequent feedback mechanisms to our development process to be able to take stock of, and respond to, our improved understanding of the domain, technology, codebase, processes, practices and team.

In my head this is always represented with the following diagram. Where the blue dotted line indicates the original direction we thought was going to be right for the project (or codebase, or process, etc), the black dots represent reflection points, and the green lines represent the course corrections that were taken to improve things. At the end of the project, we ended up with a product or a way of working that we would never have envisaged at the start.

Inspect and adapt

Inspect and adapt

This is why I am such an advocate of having regular, frequent retrospective meetings throughout the course of a project, as they provide these important points of reflection and course correction. However, Retrospectives are only as valuable as the improvements they instigate. Sometimes, even though a team may have identified the right area of their project/process/codebase to improve, the corrective actions they decide on may fail to have a discernible effect. For example, a team may want to introduce a weekly customer support rota because the entire group is feeling impeded by the number of support requests being received.  This rota is drawn up and is respected for the first week, so things start to seem better. Beyond that first week though, there’s a good chance the rota will start to get forgotten and the problem will return.

Corrective actions that are destined to succeed often have a tangible effect on, or introduce a new artifact to, a team’s day-to-day life.  In my example, the support rota is much more likely to become entrenched if there is a visual token reminding people every day that it exists and is something they agreed to do. In my team we’ve done this by placing a big picture of an ogre on the desk of the person on rota duty.

The Support Princess

The Support Princess

When a support request comes in, there is no debate about who’s responsibility it is to ensure the request is handled.  More importantly, the fact that our ‘Support Princess’ token is so big and unappealing means that when a team member’s turn on the support rota is over, they are very quick to hand the duty onto the next person, and the rota cycle continues.

Plus, there is something strangely satisfying about placing a silly picture of an ogre on your colleagues desk.