Key Questions Retrospective Technique

New Agile teams tend to place a significant emphasis on the retrospective meeting. When an issue rears it’s head, they often say “we need to talk about that in the retrospective” rather than deal with it there and then. The problem facing teams who do this is that having placed a lot of emphasis on the meeting in advance, the retrospective can go off track, focus on unnecessary details or sometimes what seemed like a big issue at the time now feels unimportant. I’ve heard people say “I remember that I was really annoyed at the time but I can’t really remember why”.

As teams gain experience it is important to work with them on giving timely feedback but when a team is in an early state of adoption and with all eyes on the retrospective, how do you go about choosing the right technique?

I was recently faced with this problem and with lots of issues bubbling around the team, growing frustration and multiple topics to deal with, I wanted something that would get the team to really open up. Originally I was thinking about the Sailboat retrospective because they were coming off the back of a sprint where they had got very little ‘done’. Identifying what would speed them up, and culling the things which slowed them down seemed ok, but it wouldn't get them talking about what they really needed to.

So in the absence of being able to pick up a specific technique, I created one and that is what I would like to share here. I’m calling it the ‘Key Questions Retrospective’ (Hat-tip to Nomad8’s Jimmy Janlen for his Jimmy Cards which provided the inspiration).

Below is a plan for how to run this technique with some example timings based on my experience.

The Key Questions Retrospective

Before the meeting

• Gather sticky notes from the board if you have a ‘discuss in the retro’ section.


• Prepare your tools and stationery.


• Ask everyone to bring a pad of paper and a pen.

Set the Scene (3-5 mins)

• Set the context and remind the team of the purpose of the meeting.


• In our case our forecasting graphs no longer made sense, if we kept progressing at the same velocity, we would no longer meet the objectives of the overall project in sufficient time. So it was important to remind the team that if we wanted to meet our shared goals, we need to do something differently (I still love the phrase ‘If you keep doing what you keep doing, you keep getting what you keep getting’).


• Explain the 'Key Questions Retrospective’ technique to the team.

Gather Data (10-15 mins)

• As with any retrospective, gather data on the work so far. E.g. How many stories/points did you complete etc.


• Use some warm-up questions to stretch the mental muscles.

• Everyone answered all three questions on their own - writing the answer on their pad at first. Then we shared them by just going round the table one question at a time.


• Then (a bit like planning poker) we got the people with extreme answers to talk to each other about why they had chosen that answer. That was good because some people had a confidence level of 0 and others had an 8, for example.

Generate Insights with The Key Questions (30-45 mins)

• Here the group answered a selection of Key Questions from the list below.


• They answered all the questions individually in writing and shared them as a group later. This gave people thinking time, which they sometimes lose in all the action which comes with starting to work in sprints and it was apparent that people were giving a lot of consideration to their answers.

Some short and instinctive key questions to start (ask people to go with their gut instinct and answer with just a couple of words).

Next ask people to tackle some more questions which require a little more thought and time (We didn’t use all of these, but this the list we chose from).

Then go around the table and everyone should share their answers one question at a time, whilst the facilitator makes notes on the whiteboard to help you spot themes and patterns.

Decide What To Do (15-20 mins)

From the themes and patterns build an improvements backlog as a team and in our case we had generated lots (and lots!) of interesting improvement areas to deal with!

It’s important to narrow things down at this point and of course not to try and solve everything at once. So prioritise (using a technique like dot voting) and then come up with concrete ideas for specific improvements. In our case we agreed on 3 experiments to try for the top items in the backlog.

Close the Retro (2-5 mins)

As always close things down, thank everyone for their participation and honesty and clarify the next steps. We didn’t want to waste the sizeable improvements backlog we had generated either, so place that on a wall next to the team ready for the next opportunity to improve.

The full retrospective took approximately an hour and a half in total but if anything we generated too many insights and we could therefore have done this in an hour flat.