Features and Stories, Large and Small
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.
The VP of Marketing says, “We can’t compete. We we need a breakout rooms feature.”
“Why do we need that?”
“Our competitors have it, and we’re losing sales.”
“What do people use breakout rooms for?”
“I don’t know. Just build it.”
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!”
The VP of Product looks at the updated backlog and asks “What are Breakout Rooms?”
“They’re separate workspaces where some of the participants can work separately from the rest.”
“How are they used?”
“There seem to be a number of different ways. Just among ourselves and our friends, we’ve come up with a short list.”
- A meeting facilitator may want to break up a meeting into separate subtopics and assign people to each.
- A meeting facilitator may want to have small-group discussions so that everyone gets a chance to contribute without it taking an undue length of time.
- A meeting facilitator may want people to work with intermittent ongoing support from a small group within the context of a larger exercise.
- A meeting may divide into multiple topics, and the facilitator wants to let participants self-select which topic interests them.
- During meeting breaks, people may want to have “hallway conversations” with others, but without the burden of everybody being in one conversation.
“Ok, those are a good start on stories. Let’s put them in the backlog. Also add a ‘Minimum Viable Breakout Rooms,’ which will be the jumping off point for any of these stories. Now, where can we do user research on these different needs?”
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
- 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.