User stories are simple, powerful tools but only if they’re written in a way that encourages communication, helps you prioritize and plan a product, and focuses on end-user value.
A great way to ensure your stories do all of this is through a user story-writing workshop. Scheduling a workshop to write user stories can make it easier to generate a product backlog.
Running a story-writing workshop opens up a whole new set of questions for people. Questions like:
- How often do you hold a workshop?
- Should it be once a year?
- Every iteration?
- Somewhere in between?
- How do you know who to include?
- If it’s just a subset of the team are you missing valuable ideas?
- If you include everyone how do you avoid conflicts and off-topic discussions?
These questions are very common. Although user story-writing workshops are an excellent way to generate a product backlog, it’s important to do them the right way. Even experienced agile teams find themselves going through a lot of trial and error to run a workshop that delivers great results.
If you are the kind of person who learns better by watching than by reading, you might prefer to learn about story-writing workshops and other user story tips in my three free videos from the Better User Stories course. It goes beyond the information presented here to include how to have workshops with multiple teams and how to prevent stakeholder arguments from derailing the workshop.
Basics of Story-Writing Workshops
Let's start with a look at the basics of a story-writing workshop.
What is a story-writing workshop?
A story-writing workshop is a time for the product owner and development team members (developers) to write product backlog items in the form of user stories.
How often do teams hold workshops?
I recommend holding story writing workshops on a quarterly basis. Product backlogs are not meant to be a one-to-one replacement for requirements documents, where you replace reams of the system shall statements with an equally exhaustive list of "As a user, I want" stories. Product backlogs are meant to evolve over time. You cannot think of every possible feature a user might want up front. So don't try.
Instead, hold smaller, more frequent story-writing workshops. Target one-hour to a full day for each workshop (depending on whether you include story mapping or not). Be sure to include lunch and a few breaks if the workshop will last all day.
What is the focus of a story-writing workshop?
Each story-writing workshop should revolve around how to achieve a single significant objective (for example, launch a new better user stories video course) or a series of smaller objectives (for example, hold a webinar about better user stories, update the BUS courseware, and begin to sell group licenses).
- A significant objective is a goal that will almost always take more than one iteration or sprint to achieve. It can often be thought of as an MVP or MMF. The product owner will determine this with the stakeholders prior to the meeting.
- A Minimum Viable Product (MVP) is a version of a product that allows a team to collect the maximum amount of information with the least effort. (For example, my free, three-video series on Better User Stories was an MVP for the larger Better User Stories course.)
- The Minimum Marketable Feature (MMF) is a chunk of functionality that delivers a subset of the customer's requirements, and that is capable of returning value to the customer when released as an independent entity. (The Better User Stories webinars I hold throughout the year could be considered MMFs for the larger Better User Stories course.)
Who participates in user story writing workshops?
Mandatory participants include the product owner (or key stakeholder or whatever you call the visionary for the product) and the whole team of developers. You might be tempted to try this with just a subset of the team, but I strongly encourage you to include all of the developers. People will be more invested and you'll get more creative solutions.
Although product owners can hold this meeting on their own, I always find it helpful to have a facilitator present. The team's Scrum Master or agile coach can help ensure the workshop runs smoothly, that everyone stays engaged, and that people take breaks.
You might also want to include stakeholders, users, and customers if they are involved in the significant objective being discussed in the workshop.
Story-Writing Workshop Agenda and Prep
Prior to the workshop, be sure to have plenty of writing tools, paper, and sticky notes or index cards available. If you are doing this virtually, you'll need to prepare a workspace in Miro, Mural, or your favorite whiteboard tool that mimics an in-person environment.
Somewhere in your virtual tool, physical whiteboard or on a large sheet of paper, write the basics of the user story template.
As a type of user
I some goal
so that some reason.
Start the workshop by asking the product owner (or key stakeholder) to explain the significant objective so everyone has a shared understanding of the goal. Then, as a group, discuss the user roles and personas that you'll need to consider.
Then, it's time to start capturing user activities as agile user stories, epics, and themes.
I find it takes about 90 minutes of brainstorming (sometimes as much as three hours) to load up a few months worth of high-priority items in a product backlog. That’s a guideline and will, of course, need to be adjusted based on the number of participants, previous agreement on the product vision, and other factors.
Next Steps
Many teams find that they feel a great sense of accomplishment after completing a workshop, but they are worried they’ve overlooked some requirements or just feel overwhelmed by the massive product backlog they just created.
That’s why at my story-writing workshops, I also introduce a way to graphically visualize the relationships between the stories you write. There are a few ways to do this, such as a goal-story hierarchy or a mind map. I recommend using a story map. You can read more about story maps in this blog post.
