One of the benefits of user stories is that they capture a need within a single sentence. So you know the user story requires further information and that you need to have a conversation at the appropriate moment with your team.
Organizing a requirements workshop or planning session is a great way to get the whole team to have such conversations.
The Process of Generating Requirements
In practical situations, the flow might be something like this:
Write some user stories.
Some weeks/months later, pick a selection of user stories to work on next.
Run a requirements workshop with the whole team (whiteboard mandatory!) to discuss the chosen user stories.
Brainstorm a list of examples for each user story.
Choose a representative set of examples.
Translate each example into an acceptance test (in Given-When-Then format).
Check that each user story now has a set of acceptance tests.
Save all of this documentation in an easy to access location.
Why Run a Requirements Workshop?
Here is a list of benefits when the whole tech team creates the requirements together in a workshop (rather than the product manager alone):
Better quality of requirements - When a team works 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 less when a group works together.
More varied perspectives - The engineers will have certain concerns, while the testers and designers may have others. When everyone examines a requirement to think about the potential problems in advance, suggests alternative 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 that some people can't agree on. But in the interest of progress, usually, you 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. It's best if 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 were created by and belong to the team. This will result in fewer problems suddenly appearing halfway through the development cycle.
If people feel like they have a say in what they are building, they are more likely to find solutions if problems emerge.
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 review. The product manager should prepare some in advance, but the team should help complete the examples.
Business people or domain experts should explain answers so the more technical team members can learn and understand.
Developers and testers should add their input, particularly edge cases (i.e., uncommon yet plausible scenarios).
Keep notes on any unknown answers to issues (don't forget people who aren't there!).
Keep the meeting focused (not just another meeting!).
A facilitator can help keep the meeting on task.
Create and use everyday language in the workshop. If people get confused by terminology, decide what language to use to solve this problem so that it happens less over time.
Communicating Intent
In his excellent book on decision-making Sources of Power, which you can access through this link here, Gary Klein provides a modified template (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 why.
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 if Nobody Knows the Answer?
During a requirements workshop, there will be times when nobody knows the answer (with certainty) to a question. 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 you get a consensus, use this opportunity to double-check if anyone has questions about the examples/requirements from the previous session.
Let’s Recap!
Requirements workshops effectively create shared understanding from a broad audience when working on a product.
The more you can collaborate and learn from real customers, the better. After all, they are the ones you are trying to help with your product.
Requirements workshops should be well planned, have some structure, and ideally be facilitated by someone with experience.
If you don’t know the answer to a question, it’s best to investigate. It’s how you turn what you don’t know into what you do know.
Congratulations! You have made it to the end of part 1 of this course. Let’s check what you’ve learned in the following quiz. When you’re done, head over to part 2, where we will explore storing in agile documentation format, starting with wikis!
Additional Resources
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)
Fifty Quick Ideas to Improve Your User Stories (Gojko Adzic)
All three of these books are excellent resources. However, Bridging the Communication Gap is essential reading for any product manager.
