In a story workshop, a small group of people from a product team get together to build shared understanding by answering the question, “What are we going to build?” Put another way, it involves examining one piece (story) of the bigger picture (story map) through conversation. The goal of this workshop is to build a shared understanding amongst the team.
The Value of Understanding the Parts of a Whole
We’re all about following the Agile process at Atomic, and that includes creating story maps. We recognize the value of having a big picture to ground us on a project. To execute the big picture, we break things down into manageable parts and make sure those parts are deeply understood on their own.
It’s like mastering a complex recipe. Think about making a flaming Baked Alaska. You already know what the finished dessert should look like—charred meringue over soft sponge cake, filled with frozen ice cream. And it must be lit on fire when serving!
But how does the ice cream remain frozen in the cake when the meringue is being charred in the oven to give it that toasted look? To master the whole dessert, you must understand its individual pieces. Otherwise, you run the risk of the ice cream melting into a pool while you’re focusing on the meringue.
Story Workshop Basics
Conducting a story workshop is simple. It should follow the basic practices of running an effective meeting. However, a story workshop is different from other meetings because its goal is to create a shared understanding about what you are going to build.
Here are some important things to consider:
1. Timing
Conduct the workshop a few days before the story is scheduled to begin. Once the story is written and the level of effort is assigned (e.g. story points), it’s a candidate for workshopping.
However, it’s important not to complete the workshop too far in advance of the iteration. Otherwise, the team runs the risk of losing the shared understanding you gained through the workshop.
Another reason not to schedule the workshop too soon is that story requirements frequently change from the time you write them to the time you work on them. At Atomic, we usually engage in story workshopping a few days before the story is scheduled to begin.
2. The team
Invite two to four core product team members to the workshop. Include a person who understands what the end user of that particular story needs, the person who will be writing the code, and the person who will handle the quality assurance testing. If the story has a design component to it, the designer should attend, too.
3. Prep work
Prepare for the workshop. Collect and gather existing project artifacts and bring them to the meeting. You should only need to bring those artifacts which pertain to the story being discussed, such as:
- Emails and notes taken from talks with the stakeholder(s) and/or customer(s)
- Sketches, designs, and wireframes
- Story maps
- Personas
4. Review & discussion
Relying on project artifacts alone isn’t enough; shared understanding doesn’t arise magically from viewing a collection of artifacts. Remember the Baked Alaska analogy? There are hundreds of recipes out there describing the end result. However, to master that complex recipe, you need to understand all of its individual parts.
In a good story workshop, the team has a chance to externalize thoughts through brainstorming, drawing pictures, diagramming, and asking questions. To help this process, bring sticky notes, an easel or a whiteboard and markers to the workshop.
And, of course, make sure that that you have reviewed the story closely and that you understand how it relates to the other known parts of the bigger picture.
5. Meeting management
Look for signs of shared understanding to know when it’s time to move on. No good meeting facilitator intends to shut down the conversation prematurely. However, due to time constraints, the meeting may need to move along rather quickly to cover the story in detail within the time allotted.
But don’t fall into the trap of trying to squash divergent ideas. Instead, allow people to express differing ideas and opinions.
Gradually, the conversation will begin to center as the team converges on shared themes. Look for cues that the team understands one aspect well enough to move on to the next one. For instance, the frequency of heads nodding in agreement increases, and direct eye contact amongst the team becomes clearly visible.
Listen for positive, reinforcing phrases such as, “That should be straightforward to test,” or, “In other words, the only UI that needs adding is,” or, “So, adding the ability to [fill in the blank] will allow the user to [fill in the blank].”
6. Documentation & sharing
Collect, document, and store meeting artifacts. After the workshop, gather the parts you collected into some meaningful order. I’ve used a plain sheet of paper to jot down bullet points about what I’ve just collected and why they are in that particular order. Basically, this process is meant to jog your memory about the significance of the pieces are and how they fit together.
Share these artifacts with the team. At Atomic, we often take pictures of our drawings and discussion points we put on the board, and we save them to a file that’s stored in Dropbox.
Busy Product Teams: Don’t Skip this Step
I’ve been on product teams during my pre-Atomic career that didn’t use story workshopping in their Agile process. Often, it was because of a heavy workload the team faced. Team members dreaded the thought of having one more meeting on their schedules, and they thought that skipping this step would save time.
I’ve also encountered the shared mindset that if the team understands the big picture, they will necessarily be able to deduce the smaller stories from it.
However, I’ve found that it’s well worthwhile to take the time to answer the question, “What are we going to build?” If you don’t, it can result in confusion, frustration, unmet requirements, and ultimately wasted time and money.