Conducting a Workshop for Creating Effective User Stories
How to reach alignment so progress becomes easier
This story was initially posted on LogRocket
Knowing where to land is fundamental but not enough.
Once you clarify the goal, you need to define what needs to happen to progress.
For decades, that step was called requirement engineering, which took months while a few people wrote the specifications. This mountainous task happened before development to identify the right things to do. Yet, it led to frustrations, as creating digital products is unpredictable, so it’s worthless to do such massive work upfront.
Agile came to change that. Instead of treating software development in phases, it became an iterative approach, improving based on learning and knowledge. Yet, it doesn’t change the fact that people need to align on how to progress. A simple and great starting point is having a user story workshop.
Let’s take this post to clarify that.
A brief note before digging into it. This week, I’ve launched the Product Discovery Done Right video course with a limited deal. Everyone signing up by July 28th gets 50 USD off by using the voucher LAUNCH-PRODUCT-DISCOVERY
Shall we rock it together?
What Is a User Story Workshop?
A user story workshop is where the whole product team and relevant stakeholders get together to build a shared understanding. They start with the goal and then explore users’ problems and opportunities and what they aim to achieve. The result is clarity on how to progress while understanding the problem space.
Unlike classic requirement engineering, the user story workshop is fast-paced and collaborative. It takes hours instead of months, and everyone collaborates instead of having specific roles. In addition, it’s a starting point that will change throughout the digital product’s journey.
The 4 Cs of User Stories
Let me clarify one common confusion. User stories are not a one-to-one conversion of classic requirements. The ultimate goal of user stories is to create a mutual understanding of the problem teams solve. Instead of blindly following requirements, teams solve problems and understand why.
It’s common to confuse user stories and forget how to use them. Understanding the 4 C’s is the key to benefiting the most from user stories:
Context: Each story lives in a context, which refers to the user in the story. Understanding the context is essential because teams may craft a misfitting solution without it.
Card: The user story itself, “As <a user> I want <something> to <value created>,” is the hard part, which is often where the whole attention goes by mistake. The card should be a reminder of a conversation, not a strict requirement.
Conversation: The most critical part is the conversation with the user or who understands her. This is the moment where the team clarifies the context and objective.
Confirmation: The last part relates to creating a set of criteria that defines the user story as achieved. Such is known as acceptance criteria, which was meant to be written on the back of a card so developers could check and ensure it’s done. Today, it’s often a list in Jira or a similar tool. Be careful and do not confuse the solution with confirmation (it leaves you free to solve it in multiple ways).
Steps to Run a Successful User Story Workshop
To run an outstanding user story workshop, you will need only three things:
Preparation
Preparation
Preparation
I cannot emphasize how important it is to prepare for the workshop because failing to do it will confuse me. Luckily, I screwed up several times already, so I can tell you what to focus on and save some time:
Define the goal: Agree with the leadership team, project sponsor, or whoever has the decision power on the goal you aim to pursue. That will set the boundary for the workshop.
Interview users: I recommend interviewing six to eight users to uncover value drivers for your aim. Consolidate the interview results so you can share them during the workshop.
Define participants: You want a diverse group while remaining small to foster collaboration. Somewhere between 5 and 8 would do. There should be at least one software engineer, product manager, designer, business person, and hopefully two or three users or someone who can represent them.
Share context: You want to ensure the participants know why the workshop will occur. That means you need to share details about the goal you want to achieve, what success looks like, and what you want to accomplish with the workshop with them. Share the interview results before the session and ask everyone to read them.
Prepare for the workshop: If in person, you need to prepare a big enough wall, a set of post-its, and pens. When remote, you need to prepare a board. It’s OK to keep that “hidden” until the event day.
Run the show: With the above done, you’re ready for the workshop.
Once you’ve done the above, running the workshop can go smoothly. Let me clarify that a bit within the user story mapping technique.
User Story Mapping
Jeff Patton is the creator of user story mapping. He wrote an amazing book that I recommend to every product person. This tech is pragmatic and valuable. It helps teams build a shared understanding of the problem and what to tackle. I love using it for user story workshops.
You can watch this video about user story mapping or understand it using the following image.
So, how do you run the show?
Write down the goal: Ensure everyone understands the goal. Make it visible and prominent enough so nobody forgets it.
Define the user: Elaborate on the users involved in achieving your goal.
Start with the activities: First, define the big picture. For that, start with high-level activities. Considering e-commerce, that would be browse, select, pay. Note that activities are verbs because they relate to action.
Define the narrative flow: As you clarify the big picture, go one level in-depth. Strive to understand the user journey. In other orders, detail each activity one level more. Again, use vers to represent actions.
Write the user tasks: This is where confusion takes place. It’s not about writing user stories; it’s about writing user tasks. This is a simplified view so you can quickly scan and understand the overall. For example, instead of writing, “As a user, I want to conclude the purchase without creating an account to keep my data private,” you can write, “Guest check-out.” Keep these as keywords because the goal is to have the big picture so you can prioritize.
Cut distractions: This part may be time-consuming but highly important. Go item by item and ask, “Would we reach our goal without it?” If you struggle to connect the card to the goal, remove it. Do that for all cards.
Draw a line: How much time do you want to invest into the goal? Given your time constraint, draw a line in your story mapping based on what you imagine you will achieve. This, combined with the previous step, will enable focus.
The story mapping exercise will take somewhere between four and eight hours. Trust me, this time will be highly paid in the future.
As you finish your story mapping, you can convert the user tasks into user stories. That would be the next step, but that shouldn’t be long, given all the context built. Now, let’s talk about writing great user stories:
Writing Effective User Stories
It’s easy to misuse the user stories techniques and have watered-down solutions. Here are a few tips for you to succeed with it:
Keep the user perspective as the focus, not the solution you want to implement
User stories are about building shared problem understanding, not meeting arbitrary requirements
Ensure that user stories relate to a single problem or opportunity, not multiple
Make sure the why behind the user story is clear. Often, people skip the last part, resulting in teams implementing solutions without knowing why
Follow INVEST principles to keep the user stories sharp
Prioritize collaboration over coordination
Learning Resources for Writing User Stories
User stories can be helpful, but messing up with them is easy. Let me give you a bit of additional resources to level up your game:
Key Takeaways
User stories heavily depend on effectively applying the four Cs: Context, Card, Conversation, and Confirmation.
Workshops, preparation, and collaboration are fundamental to thriving with user stories.
User story mapping will help you see the big picture, but you should not treat that as final but as the starting point.
Use the techniques to foster collaboration, not to limit it
Don’t write “solution” stories. Always keep the user perspective as the focus.
Here are a few ways I can help you even more:
Upgrade your subscription to Premium and get one deeply thought newsletter per month (20+ minutes reading) plus access to 300+ episodes
Have a lovely day,
David
Wow, amazing David! Here where I work, we do kind of Workshop to create the User Stories but I didn't have the idea that in fact, our Ticket & Issues meeting was in fact, a Workshop haha
Thanks for sharing!