Retrospective Technique #1: Tell a Story
Tell a story — in 100 words or less
User stories are an important aspect of Agile software development. This article describes a technique where team members employ a modified form of story writing in an Agile retrospective context.
If you are the facilitator for the retrospective (e.g., Agile Coach, Scrum Master), you will find this to be a simple technique to introduce. Here is a suggested approach:
- In advance (when planning for the retrospective), choose a set of words that retrospective participants must include in their story (let’s call them “shaping words”). Simply stated, the nature of the exercise is to write a story of no more than 100 words, where the topic is the sprint/iteration that just ended, and the shaping words that you specify must be used at least once in the story (see the Examples section below).
- The shaping words that you choose to require participants to use will have a direct impact on the nature of the stories people write. That is to say, those words serve as “guard rails” for the exercise. Let’s say you’re going to require the use of five shaping words/phrases. Those words/phrases might be something like “start,” “stop,” “keep doing,” “do more of,” “do less of.” Or you might choose to specify the use of four shaping words, such as “drop,” “add,” “keep,” “improve.”
- Make sure all retrospective participants have something to write with and something to write on (any physical media, such as note cards, or virtual media, such as a text editor or similar app, will suffice).
- Timebox the writing portion of the exercise (give participants no more than five to ten minutes to write their stories).
- Timebox the discussion portion of the exercise, which consists of two parts: 1) have each participant read their story; 2) have a team discussion, focusing on common themes across the stories (use your discretion when it comes to timeboxing this part of the exercise; you may find this technique opens up some very interesting avenues for team discussion).
- Use the outputs from the discussion to inform the Action Items that you choose to focus on as a team during the next sprint/iteration.
Variation 1. You might want to consider laying out some other guidelines before having participants write their stories. For instance, you might choose to require that they write their stories in the first person singular (i.e., no personal pronouns other than “I” are allowed). This might be a particularly important stipulation for new teams or for teams that are going through a difficult period, because it forces the focus of their writing to be on what they did during the sprint/iteration, not on what someone else did or did not do.
Variation 2. Depending on team size and composition, rather than having each individual write a story, you could have the team divide into groups, where each group writes a story. Reasons you might choose to do this might include cases where a team is particularly large, and thus time might be a limiting factor, or cases where some team members might be uncomfortable with writing and sharing their own story.
Variation 3. If the team has had a particularly good sprint/iteration, or just because you want to unleash their creativity, consider using a random set of shaping words that really have nothing to do with retrospectives, agility, or software development.
Variation 4. (this suggestion courtesy of Ben Linders). Have the team choose the shaping words.
Example 1. Let’s say you require participants to use the shaping words “mad,” “sad,” and “glad.” A participant might write something like this: “I was really glad that the demo went as well as it did. But I was also mad that we kept having to go off on tangents at the end of the demo. And a couple of things that made me sad were that we had to open a defect because of something we could not address during the iteration, and also when I found out that we are losing a team member.” (73 words)
Example 2. Let’s say you require participants to use the shaping words/phrases “great,” “not great,” “start doing,” “stop doing,” “keep doing.” A participant might write something like this: “We have to stop doing testing mostly at the end of the Sprint. And we need to start doing more to help ourselves collaborate besides during the Daily Scrum. It was great that the additional environment we needed got set up earlier than we expected. But it was not great that we changed a story significantly after the Sprint started. One thing I hope we keep doing is going out for lunch one a week as a team.” (79 words)