Imagine you work for a company that produces a videoconferencing system. You’ve done pretty well with it, but you’re middle of the pack of competition. Then there’s a worldwide pandemic, and the market for videoconference software explodes. There’s a silver lining in this terrible event. A rising tide lifts all boats, right?

Maybe not, if the competition has more of what the customers want. It’s critical to remain a viable choice in the eyes of customers.

So, a new feature, Breakout Rooms, is added to the product backlog. It’s a Feature because it’s a named part of the product rather than a capability the product gives to the customer. It’s a noun, not a verb. If you were selling this product in a box in the grocery store, you might add a banner across the top corner saying “Now with Breakout Rooms!”

These are Big Stories. Some people call them Epics, but I think that’s too grand a name. Allen Holub recommended calling them Fuzzy Stories, because they’re not well understood, yet. That’s true, too. Big Fuzzy Stories are good enough for early planning.

Notice that these stories defined in terms of functionality—what people want to do. We may give them names to talk more conveniently about them, but they have more in common with verbs than nouns. Since they’re fuzzy, we might name them based on the situations where they seem important. Let’s call them Assigned Subtopics, Small Group Discussions, Persistent Support Groups, Self-Selected Topics, and Hallway Conversations so we remember our intention for them. These names cover a bit more than the functionality, itself. The names also hint at the context in which we’re considering the functionality.

These particular stories seem to have a lot in common in terms of functionality, which is what prompted the thought of a “Minimum Viable Breakout Room.” And none of them seem particularly larger or smaller than the others—at least not as far as we currently know. Research with actual and potential customers may tell us differently. For now, though, we can work with our imperfect understanding.

Looking at a bigger picture, we might categorize this work within a larger theme. We might call that theme Facilitation Tools since these stories are all variations of things that a meeting facilitator might want in different situations. I can imagine having other themes, such as Participant Experience focused on making it easy for those not facilitating, Historical Record that covers recordings and saving other artifacts to review later, and Scaling to consider the efficiencies needed to host larger meetings.

While we gain more knowledge about specific needs in these areas, and perhaps uncover more, we can start working on the Minimum Viable Breakout Rooms. We might use Example Mapping to slice this Big Fuzzy Story into small slices of functionality for implementation, each with identified scenarios that the system can perform when the slice is completed.

It seems that Minimum Viable Breakout Room is pretty big and fuzzy, also. We have a number of questions, and that clearly indicates fuzziness. The bigness is indicated by the considerable number of rules and examples we’ve identified. In fact, it was hard to stop at this point, and not create more rules and examples for them. We’re excited to build this new feature! But we also want to guide what we build based on a more complete understanding of customer needs. At the moment, we’re just trying to get started building some of the primitives that we “know” this story will need.

Let’s split this story up into smaller, more focused development stories. One common method of splitting is by “business rule,” which are the blue cards. We could turn this into 5 development stories without thinking about it.

But now that I think about it, I think I’d like to combine the first two rules into one story. Why? Because I think there’s some synergy between them. And I don’t want the isolation between rooms to be dependent on some magic of people being placed in them. That’s just a hunch.

And the “Closing and Reopening” rule–it seems like there may be a lot there that we’ll discover in your user research. We were having a hard time cutting off new ideas, and perhaps this one is a “nice to have” that isn’t needed for “minimum viable.” So let’s put that one aside as a possible future story and make three story cards for development: Room Isolation, Room Create/Delete, and Room Name. If you’re doing Scrum, you would use these for your Sprint Backlog Items.

Stepping back, we see a hierarchy of

• Themes
• Features
• Big Stories
• Development Stories
• Business Rules
• Examples or Scenarios

These aren’t a strict hierarchy. You may find exceptions where some levels don’t seem to apply. That’s OK. The nomenclature is there to help you do the work, not control you and prevent your from doing what seems appropriate.