How to share user stories with your team?

“Tell me, I forget.

Show me, I remember.

Involve me, I understand.”—Chinese Proverb

Almost all Agile teams have group time for product owners or business analysts to share user stories. On the Mingle team, it happens everyday in a mix of scheduled meetings and ad-hoc conversations. I consciously practice the following three tactics to ensure quality interactions.

1. Why?

   We put a lot of effort in establishing team-wide shared understanding about “why we are doing this?”. I like using narratives to do this: telling a story of your user story.
   
   Currently, our team is working on a new editor for Mingle. During the kick-off, we immersed our team in one of our customer’s life. We showed the customer’s photo, reproduced a scene from her daily work, and quoted what she said about her pain points.
   
   Doing this can activate the team’s creativity to solve problems for customers. The persona's name can also be used as shorthand, making it easier for the team to reference in subsequent conversations.

2. Where are we?

   In Agile teams, breaking work into digestible stories creates the need for a “map” to track and locate them in the overall user journey. When starting work on a specific story, never hesitate spending time syncing the audience with the context.

   You can employ many different tools such as user story mapping or an activity map to track and share your “current location.” If you have access to a whiteboard, draw it out. Imagine yourself as a zoomable canvas that carries the map of your team’s work. Choose the the right zooming level and use your own style to bring everyone to the same page.

3. What are the Acceptance Criteria?

   To define “what” the Acceptance Criteria are, I like drawing them out on the whiteboard and letting the team summarize what they see.

   

   Here is what I do:

   • Using markers with more than 2 colors, draw the existing page as the “Given” part.
   • Using a different color, point out the event trigger, the “When” part.
   • Continue to draw out the expected “Then” part.
   • Pause, let the team ask questions or make comments.
   • Using a different color (I use black), capture the list of questions and comments.
   • Answer the questions on the list and add items which are important but haven't been brought up by the team.
   • Use this as a checklist along with with the “given-when-then” as acceptance criteria on the user story.
   

FAQs

Why don’t I just use screenshots or hi-fi prototypes?

They contain too many detailed page elements. Sketching omits noise, keeping the conversation focused and limiting analysis to include just-enough detail. Whiteboard sketching is generally better than a static picture, because you can change it as the conversation goes.

What do people do when I am drawing?

Don’t worry about those few minutes. Revealing the story progressively helps your audience become more actively involved.

What if I have ten scenarios for my story?

I only draw out the happy path in the “given-when-then” format to establish the basic flow of the interaction. For the negative scenarios, I use a table or matrix, depending on situation.  A bit of variety can help both presenter and audience not get bored.

What’s after these 3 things?

Sharing user stories is not a one-time thing. We need remain flexible to accommodate changes. Don’t freeze the business requirement after the group communication. Keep the conversation going as needed; keep improving as we are committed to in the true agile spirit.