One of the benefits of user stories is that we capture a need within a single sentence. We know the user story requires further information and we know that it's necessary to have a conversation at the appropriate moment with our team.
Organizing a requirements workshop or planning session is a great way to get the whole team together to have such conversations.
The process of generating requirements
In practical situations, the flow might be something like this:
We write some user stories.
Some weeks/months later, we pick a selection of user stories to work on next.
We run a requirements workshop with the whole team (whiteboard mandatory!) to discuss the chosen user stories.
We brainstorm a list of 'examples' for each user story.
We choose a representative set of examples.
We translate each example into an acceptance test (in given-when-then format).
We check that each user story now has a set of acceptance tests.
We save all of this documentation in an easy to access location.
Why run a requirements workshop?
Here are a list of benefits that result when the whole tech team creates the requirements together in a workshop (rather than just the product manager creating all requirements on their own):
Better quality of requirements - When a team of people work collaboratively you get better results than if one person does the work. While one person may miss something or make a mistake, the chances of that happening are reduced when a group works together.
More varied perspectives - The engineers will have certain concerns, while the testers will have other concerns, and the designers might see other issues. When everyone examines a requirement to think about the potential problems in advance, suggests alternative candidate solutions, and weighs the pros and cons of each, it generates better solutions.
Higher levels of consensus - It is natural that members of the group see things differently, and as information is shared, people often change their opinion. The team needs to achieve consensus on how to move forward and it is easier to achieve this consensus when everyone is in the same room and working on it together. There will always be one or two issues which some people just can't agree on. But in the interests of making progress in our workshop, usually we can find solutions that everybody can 'live with' on these one or two tricky issues.
Greater buy-in - A product manager may have user stories and some acceptance tests prepared in advance. My suggestion is that the product manager presents no more than 70% of the user stories and acceptance tests and lets the group finish the requirements during the session. You want a situation where these requirements belong to the team and the team created them. This will result in fewer problems suddenly appearing halfway through the development cycle. If people feel like they had a say in what is being built, then if a problem does emerge later, the team usually comes with the problem and possible solutions rather than "oh no, here is trouble".
How to run a requirements workshop?
Gojko Adzic, author of 'Bridging the Communication Gap' suggests the following tips for a requirements workshop:
Start off the workshops with a set of examples (or scenarios) to be reviewed. The product manager should prepare some in advance but the team should help to 'complete the set' of examples.
Business people or domain experts should give answers but also should explain them so that the more technical members of the team can learn and understand
Developers and testers should add their input, in particular edge cases (i.e. uncommon yet plausible scenarios)
Keep notes of any issues where the answer is not known or would be best known by somebody who is not in the workshop.
Keep the meeting focused (not just another meeting!).
Selecting a facilitator can help keep the meeting focused.
Create and use ubiquitous language in the workshop. Use the workshop to evolve the language. If people are getting confused by terminology, decide the best terminology to use to solve this problem so that over time this happens less.
In his excellent book on decision-making Sources of Power, Gary Klein provides a modified template (from an original source by Karl Weick) for how a commander can effectively communicate his intent:
Here's what I think we face
Here's what I think we should do
Here's what we should keep an eye on
Now, talk to me
This can be a useful framework when introducing a need/requirement/user story to a group of people who are not very familiar with the subject matter but are experts in related areas (e.g. the current technical behavior of the system).
What to do if nobody knows the answer?
There will be times during a requirements workshop when a question arises that nobody knows the answer to with sufficient certainty. During the workshop:
Identify areas that require more research or greater certainty.
Identify who is the best person to do this research. If a team member has the most appropriate knowledge base for investigating a question, ask if they will do so and report back. Otherwise, take the responsibility as PM to research the issue and report back to the team.
Schedule a short follow-up meeting so that any uncertain areas can be all agreed on as a team. Once consensus is achieved, use this opportunity to double check if anyone has questions about the examples/requirements from the previous session.
The three best books I have read on the topic of requirements (user stories, acceptance tests and workshops) are:
User Stories Applied (Mike Cohn)
Bridging the Communication Gap (Gojko Adzic)
50 quick ideas to improve your user stories (Gojko Adzic)
All three of these books are excellent resources. In particular 'Bridging the Communication Gap' is essential reading for any product manager.