Mike Lyons runs story writing workshops to break massive features into smaller pieces. Developers, stakeholders, and users write user stories together using the "As a user, I want... so that..." format. The goal is shared understanding, not perfect documentation.
Features can sometimes seem like elephants. They're usually pretty big, and trying to build one all at once is like trying to eat an elephant in one bite. It just won't work because everyone knows the best way to eat an elephant is in a taco. Elephant tacos. I love the elephant taco joke. You have to leave it. Just leave it for me. It's not funny. When your team looks at these massive chunks of work in the backlog, they might feel overwhelmed. So that's why we need to break them down into smaller bite sized pieces. And one of my favorite ways to break down features is to get everyone in a room for a story writing workshop. I've used this approach for years and I found it to be a really good collaboration technique. But you might be wondering, why is it called story writing? Well, I recommend having people write their ideas as user stories. It's a common way to capture work. A user story is a simple description of a customer need, written from the user's perspective and typically following the format. As a type of user, I want the thing they want to do so that the benefit that they'll receive. It's a tool to capture customer requirements in plain language that everyone can understand, focusing on the who, what and why rather than the technical details of how it will be built. Consider the schedule predictor feature for taskflow. That's a pretty big feature, so it might contain multiple smaller pieces of work written as user stories. Something like as a project manager, I want to see a predicted finish date for my project that updates automatically so that I can adjust resources or scope before we miss our deadline. Or how about as a team lead, I want to get an alert when my project is predicted to finish late so that I can make schedule adjustments while we still have enough time to meet our target date. Those are pretty good, pretty easy to understand. This structure helps us maintain focus, building the features our product needs one small part at a time and always delivering value each step of the way. Now, the real goal of user stories, and this is really important. So get this the real goal of user stories is shared understanding. Shared understanding of the problem we're trying to solve, who we're solving it for, and why it's important. And if you've been around product management at all, you should be familiar with user stories. And I'm just giving it a bit of a head nod here, but if maybe you're not too familiar or just need a refresher, I've got a link below to a deeper dive for you to check out. Okay, now, real quick. Before we dive into how to run a user story writing workshop, make sure you've gathered those feature ideas from your value proposition canvas. They create natural groupings for the user stories we're going to create and ensure that everything ties back to real customer needs. Okay, so block out two to three hours. Get everyone in a room, real or virtual. You'll need your developers, stakeholders, and even some actual users in the room. They know things you don't. For example, your developers, they know what's technically possible. Your stakeholders know what matters to the business. And your users, well, they know what actually works and what doesn't. The structure is pretty straightforward. In the first 15 minutes, tell everyone why they're here and what you're trying to build. Use your value proposition canvas as a vision to set the stage. Then you'll present your features to the group. Think of them as guardrails. They help keep the story writing focused while still leaving room for creativity and innovation. For example, maybe you want to break down that schedule predictor feature into more stories. You'd ask the participants to think about all the ways this feature could help project managers and other customers make better decisions or solve customer pains. From here. Once we've set the stage, we want to break into small groups as needed and start gathering information about what to build for. Use the user story format to help capture the work we want to do now. Don't overthink it. If you can't explain what you want in one sentence, you're probably trying to do too much. I would time box the creation of stories to about 45 minutes or so. Then bring everyone together and make all the stories visible. You might do this in an online collaborative space or even as sticky notes on the wall. Look for duplicates as well as themes or patterns that emerge, and then begin to group things together. Look for major gaps and ask hard questions now, not weeks from now, when you're potentially working on the wrong thing. And after the workshop, you'll have a list of stories that actually mean something. You'll know what's important and why, and everyone in the room will. They'll understand what you're trying to build. A number of things can go south on you. Here's what usually goes wrong and how to avoid it. People write novels instead of stories. Stop them if it's longer than a sticky note. It's too big. The loudest person dominates. Don't let them get input from everyone, especially the quiet ones. People jump to solutions before understanding the problem. Pull them back. A focus on what your customers need, not necessarily exactly how we'll build it. So there you have it. Story writing workshops are a powerful way to break down big features into manageable pieces. They bring together the right people, tap into collective wisdom, and create clear, actionable stories that your team can actually build. So give this a try. I think you'll be surprised how much better your backlog becomes when you make story writing a team sport.
