Tips for Effective User Story Gathering Meetings
The typical approach in gathering requirements for an agile managed software or hardware development project is to first conduct user role modeling meetings. A collection of developers, product people, marketing, subject matter experts meet to brainstorm all the different user roles that will interact with the system being created.
After gathering the list, the next step is to generate a list of user stories. One very effective way to do this is to conduct user story gathering sessions, where the group of project members and customers iterate through each user role, brainstorming all the ways the user will interact with the system. Often, a paper prototype outlining a rough workflow is used or created during the session to facilitate the conversation.
Mike Cohn has done an excellent job describing both of these activities in his books Agile Estimating and Planning and User Stories Applied. I’d like to suggest a few tips that have helped make these activities even more useful in generating requirements documentation
- Prepare paper prototypes before the user story gathering meetings with the obvious stories. This will give your meeting attendees a good starting point, serve as examples of how to do a prototype, and speed things along.
- Use Visio or Powerpoint to build your paper prototypes instead of a whiteboard or notecards. Having an electronic copy I can pass around to distributed members of the team is very useful. Plus I find that I am often flipping between multiple workflows during user story gathering meetings, which is hard to do if you drew everything on a whiteboard that might be already erased.
- Start with the user role with the largest role in the system and work your way through each user role in descending order of system interaction. This will cause you to write up a lot of different paper prototype workflows. As you get further down the list of roles, you will find that the paper prototypes you need to facilitate the discussion are mostly already built. (Yet another reason to keep your workflows in an electronic format)
- Don’t forget to gather stories for the hidden users roles! I find it extremely useful to work through the system as the role of developer, designer, project manager, qa manager, product owner, suppler, etc. Example stories you could generate as a project manager for a new web application project could be:
- As a project manager I want to conduct a PCI compliance gap analysis for my planed network architecture to make it easier to attain compliance later.
- As a developer, I want to setup a continuous integration server for the project so that our unit tests are executed regularly.
I hope you find these suggestions useful.