Writing user stories... a retrospective of the workshop in Bologna

Caveat: this post is a spoiler of the writing user stories role game I've played in Bologna. Credits: it is mainly based on the Agile Requirement Exploration session in XP Days BE 2007 by Dave & Brett, but it was modified by me in structure. So, enough for the introduction.

Let's say you have 25 people sitting 5 per table. Each one is a team. The goal of the game is to practice user stories in a controlled context, so to highlight improvements for participants, and in particolar to understand: who is responsible, who feels responsible; how much our presumtions on the domain influence our design. I started with a brief pantomime about the risk of silver bullets, then I collocate with the poster user stories for people who aren't used to write them. Each team has people who don't know each other at best, or at least don't work each day one with the others. It is important that at each table there is at least one person who actually wrote user stories -- or he or she think so.
I didn't explain the standard "syntax" of user stories (the mantra as-a-role-I-want) and I soon realized that it would be better to do it. Next time.

Then, the first pomodoro starts: each team is given a paper sheet with a 5-line specifications, sufficiently unclear, from the customer. "This is what I want. Do it." The topic is a web site that seems to be an iTunes clone, but it isn't. Each team can call me or Fabio (playing the the customer's role) for explanation, but we can't be in different tables at the same time. Ergo: customer time is precious, don't waste it. In the second pomodoro I lead a small retrospective in form of a dialogue mapping (see my PhD minor dissertation about this particular technique) with the following key questions: which difficulties? how much the customer (not) on site influence? Fact: requirements should always be elicited from the customer in any case.

In the third pomodoro some new rules come. Ok, you need customer on site. We take randomly one person per table being the customer proxy and Fabio conducted them out of the room. In the room, I told each team that inside trading comes: swich your cards between the tables! This is an innovation I thought, so people can (a) rewrite stories by heart (usually the result is better than before) and (b) see how others work. In the meantime, Fabio give an extra paper sheet to the proxy with the detailed list of features based on the 5-lined requirements. Furthermore, each customer proxy must choose a cognitive style (other innovation), as NPL defined: V for Visual, A for Auditive and K for Kinestesic. That means that the proxy plays a role and he or she understands "only" the questions put in the correct cognitive style by the team. For example, a Visual proxy wants to have sketch of the GUI, while a Kinestesic one wants pantomimes.

After a while, proxies come in again, but they sit in a different table... Additional rule: only the proxies can ask for help to me or Fabio as the customers.

The final pomodoro is a general retrospective starting from the counting of features found by each team. It is worth noticing that there is no correlation between teamresults and the cognitive styles... A constructive critique was to add an other pomodoro for teams, so that cards can be prioritized. That sould be fine: even if the workshop lasted more than 2 hours, people was so enthusiastic they missed the coffee break as they chosed so. Incredible, isn't it?