If you find yourself on a large agile transformation programme, one of the issues you’ll probably struggle with is ensuring good quality User Stories across many feature teams. This can be especially difficult if you have limited coaches and aren’t able to spend enough dedicated time with each team, let alone each BA.

You will probably try many of the standard approaches to improve the overall quality but even though there may be some improvement, it may not always be as fast or as consistent as you would like. You may try focusing on the team’s Story Reviews but because the teams may be quite young to the agile game, they aren’t necessarily aware of the required level of detail. You may also try allocating coaches to teams and get them to go through a random selection of their stories and provide the BAs with feedback.  But you know this isn’t sustainable – the teams should be able to manage and improve the quality of their work themselves. Then an idea came to me – why not take the speed dating concept often used for feedback and adapt it for story reviewing?

So how does it work? Let me take you through it.

1. Find 2 BAs from the team that will run with the prep and the logistics for the event. These 2 serve as the facilitators and timers.
2. Prep the BAs that they need to prepare a bunch of their stories that they plan to have reviewed. It’s easier to have these ready electronically on whatever system you use on the programme so all the BAs need to do is have their laptops FULLY CHARGED and connected to their network.
3. Book a large enough room with a large enough table (perhaps use the biggest boardroom you can find) so that they can all fit around it and sit  (relatively) comfortably next to each other.
4. Now pair them off by starting at one point and moving around the table, allocating first “A” then “B” repeatedly until you’ve paired everyone together and allocated everyone either an “A” or “B”.
5. Explain the rules of engagement.
   • The goal of the session is to provide feedback to each other on the quality (instead of the specific content) of the user stories. The INVEST principles should be used as guidance for the feedback. Feedback on the presentation of the story is also recommended as an important aspect of a BAs role is communication.
   • Everyone will be given 20 minutes with their current pair.
   • This will be divided into 2 parts of 10 minutes each.
   • “B” will choose a story from “A”s list of stories. “A” then runs through the story as if doing a User Story review. Once “A”  has provided the overview, “B” provides feedback.
   • After 10 minutes, “A” and “B” swap around.
   • After the next 10 minutes is up, the pairs are given a minute or two to switch to their next pairs.
   • The “A”s will stay in their seats for the duration of the event.
   • The “B”s  will move clockwise to the next “B” seat once they have completed the 20 minutes with their current pair.
6. Repeat this 3 times.
7. With 15 minutes to introduce the concept and explain the rules of engagement, and 60 minutes for 3 pairings, you will end up with a session that lasts 1 hour 15 minutes in total.

When we tried this on a large programme, we also held a retro a few days afterward and gathered some great feedback.  Here are some of the things we picked up during the session as well as some notes from the retro:

• The interaction between people was great! Hand signs and facial expressions abounded everywhere.
• You get to see the work of other BAs and the scope from the other teams, which you don’t always get exposed to regularly.
• We picked up good ideas of other content that could be useful in stories, eg. System Decomposition diagrams, non-functional requirements we’d missed, etc.
• When the BAs talk the stories through they can ‘fill in’  details that have been left out of the written story. BAs listening should watch for this or the BA giving feedback should read the story themselves.
• We initially started with 5 minutes each, but moved that up to 7 minutes, as some of the BAs hadn’t finished summarizing the story by the time their 5 minutes were up. In the retro it was decided that 10 minutes per review would be better.
• The venue wasn’t quite big enough to hold everyone, so it was a bit crowded.

The teams we ran this with were overwhelmingly supportive of the event, so much so that they decided to hold it again every First Friday of the month.

Just a caveat – this shouldn’t be seen as a replacement for collaboration in the team, but rather as an additional mechanism to improve quality and collaboration. And it’s fun!