 User poems. Topic. Many teams we work with make great use of user stories as a means of representing user needs and functionality that's required within the product backlog. User stories, while far from mandatory, have become an incredibly commonplace site within agile teams and can be very effective in giving a better indication of what is needed, by whom and why. However, we also regularly hear teams ask for help making their user stories better. And this retrospective looks into one way that you might want to start the process of inspecting and adapting your product backlog process. You'll need the following resources. Some example user stories from your product backlog. If your team doesn't use user stories, this retrospective could still work with whatever you use as requirements for your product or project. Ideally, have your product owner present and may be considered inviting some users. You'll also need some index cards and some marker pens. This retrospective will typically last somewhere between 45 and 90 minutes. Hook. Welcome everyone and tell them that you're going to introduce the goal of the retrospective with the following limerick. A team from the town Balamori grew tired of the old user story. Though it seems somewhat strange, they used poems for a change, which led them to rhythmical glory. Explain that in this retrospective, we're going to explore the value of our user stories and perhaps explore alternative methods of representing user needs within our product backlog. Ask if everyone is familiar with the limerick as a form of poetry. If anyone is unfamiliar with limericks, explain that each limerick is five lines long with lines 1, 2 and 5 rhyming with each other and lines 3 and 4 rhyming with each other. Lines 3 and 4 are shorter in length than lines 1, 2 and 5. The limerick that we use to introduce the session is an example. Events. To start off the events section, read out the following user story. As a user, I want to back up solution for the photos on my iPad. Ask the team to list what they think is good about this user story and what they consider to be bad about this user story and capture their thoughts on a flip chart. Examples of things they might say are it leaves the solution open to the team, there are some specifics, so it isn't too big or open-ended. For example, it states iPad, which means we don't have to design for all other tablets or other devices, and it states photos, but we don't know anything about the user and there are no constraints on the user story. We don't know why they want to back up and there's no engagement between the writer and the reader. Ask the team to draw some conclusions from their findings about what makes a good user story and capture these on a flip chart sheet entitled A Good User Story, and ask the team to finish that sentence. Next, explain that for the purposes of this retrospective, we're going to experiment with user poems instead of user stories and read out the following limerick as an alternative to the previous user story. A tool to preserve precious memories is where we should put all of our energies. For John the new dad, fear of losing his iPad is one of his life's biggest enemies. Ask whether in this example user poem the team have a sense of who the feature is for, what they need and why they need it. Hopefully they agree. Now take an item from the product backlog and tell the team they have eight minutes to come up with a limerick for it. Remind them of the rules of the limerick structure and the characteristics of good user stories or user poems from earlier. If you sense people are worried about the prospect, then suggest the following. First of all, list out the key words that come to mind, perhaps making use of an online thesaurus. There are websites that will help you find words that rhyme, perhaps work in pairs and also don't worry about it rhyming perfectly. Meanings. We're now moving into the meanings section and at this point I want to emphasise and you may wish to as well that the point here is not to start an uprising and force all teams to replace user stories with user poems. Instead, hopefully we can create this section to reflect on the process of writing, telling, sharing and discussing user needs in whatever format and find ways to improve it. Ask the team to consider what they can take from this exercise. Some of the usual learning points that come out of this retrospective include it's interesting how different people consider different aspects so perhaps it's better if user stories or poems are not written just by one person in isolation. Also, user stories or poems are much more powerful if they create a connection between the reader and the user in question. Else. Instead of limericks you may choose to use something different to start the conversation about the value of your product backlog items. Remember, the point is not about structure but rather to focus on finding a way to create a shared understanding of purpose while also having a little fun. With this in mind you might want to use a different form of poetry such as the haiku or perhaps encourage teams to draw the user need or even act it out. Perhaps they could model the user need with Lego blocks or modeling clay. Decisions. In the decisions section re-emphasize that the point was not to abandon user stories although if the team really like user poems then that's fine but rather to just revisit how best to extract maximum value from the process. Encourage the team to take some more product backlog items and rewrite them even just by enhancing the format of the user story in order to increase the value they could get from them. Perhaps you could finish the retrospective with the following limerick. A story conveys user needs. If written well the team often succeeds. It's not the writing or spelling the values in the telling so think hard about how well it reads.