How to run a user story workshop?
I find lots of trainers have a hard time running a user story work. Moreover, these workshops do run with several slide shows instead of hands on exercises. I would like to get my dirty with lot of work to do in a workshop. There is a lot of value for teams writing the stories rather than, glancing through some theory examples.
I would prefer the following steps to run a User story workshop.
- Form a group of 3-5 people who understand the purpose of the product. 3-5 seems to be the magic number. Any less and you might miss some ideas. If you add more people, it slows the process down and there are diminishing returns on the quality of ideas generated.
Let the team to come up with a vision of own dream product. Propose them to write high level features for the vision. Clearly explain what you mean by a feature. (Example: Login page for a portal is not a feature). Take each feature and identify the high level requirements on color sticky notes.
- Introduce the phrase “EPIC” and tell teams to break features into epics in different color sticky notes. Make a wall map and help the teams to paste the epics exactly below the features. When teams establish features and epics relationship, I would work with them to make team write high level requirements for each epic. Introduce User Story with an example and its intent. Help teams understand various formats of User stories. Convey the importance of identifying User Personas at this stage. Show some examples of splitting user stories. Give few guidelines of dos and don’ts as well as pitfalls and traps when writing user stories.
- Start the exercise by asking teams to write high level one liner as requirements for each epic in silence. Each person takes the same colored post-it and silently writes down one user story per post-it. Once everyone has finished writing their post-its, have each person read their post-its aloud. If anyone has duplicates they should be removed at this point.
Depending on the size of the epics it can take 3-10 minutes to get all the major user stories. You can watch the body language to see when team is done. You can observe that the group goes from huddled in at the beginning to standing/leaning back at the end. It is likely that each post-it starts with a verb. (eg. Compose E-mail, Create Contact, Add User, etc) which forms the walking skeleton” of the map. Ask teams to stick all user stories exactly under the related epics. This might be their first ‘aha’ moment for silent brainstorming.
- Next ask the team to group the sticky notes in silence. Ask team to move similar things close to each other and dissimilar moved farther. Use silent grouping simply because it is faster than grouping them out loud. If duplicates are found, remove them. Groups will form naturally and fairly easily. Once again, body language will help you see when they are done – usually 2-5 minutes.
- Introduce acceptance criteria with an example. Help teams write acceptance criteria for individual stories. Now talk about the non-functional requirements. Ask the team to come up with non-functional requirements for the same stories. Arrange all the stories on the wall, and help teams order them, ask them use slice the stories either by date or scope.
- Explain sizing of stories using story points and help teams size all the stories. Please have someone role plays the Product Owner. Let the trainer himself act as a facilitator for story points sizing exercise using planning poker.
- Finally, I like to take all the user stories in the first release. I recommend the team do some serious user story slicing to make sure that we have sliced the first release as thin as possible.
I see there is lot of value and motivation when team s to come up with their own vision and write down the stories. The essence of the workshop may be lost when I give pre-cooked user stories to the team. What do you think?