Where Do User Stories Come From? Part 2
In my last post I introduced the topic of User Story Writing Workshops. These are planning meetings where a product owner can gather a team (existing or potential) together where they collaborate to create a list of user stories to be used in seeding a product backlog.
It’s a wonderful technique for generating loads of stories-quickly! It also has some serious side-benefits that I think are valuable as well. But, enough of that…
Let’s Get to Writing Stories
There are many ways to attack story writing in groups. I’ll be emphasizing my preferences here, but don’t let that limit your own approaches. The key element is to:
- Generate as many stories as possible
- Across as broad a spectrum of features / work as possible
- As quickly as possible
- And along the way, collect as much Meta-Data as you can
I like to have the roles drive the brainstorming, so for each role, I’ll allocate 10-15 minutes of story writing time. Usually, I start this with the entire group-so everyone is writing. I’ll “call out” each story as I collect it to let everyone know what’s being written and to reduce the number of duplicate stories produced.
Once you have a large set of stories, I like to stop action (writing) and get the team engaged in “cleaning up” the stories. If I’ve posted them on a whiteboard, I’ll invite the entire team up to the board to start removing redundant stories, consolidating stories where there are obvious relationships, and writing new stories to fill in any ‘gaps’.
Often I’ll oscillate between writing as a group and this collaborative clean-up effort. It helps to keep the whole group engaged in the process and it maintains energy and focus in the meeting. Once you’ve developed stories for each one of your roles, you’re essentially done with “Round #1”, Then you move onto massaging (ordering in time sequence, considering risk, filling in gaps and dependencies, etc.) in your stories.
The Chess Analogy
Once you have a fairly healthy list of stories, I like to spend a fair amount of time on ordering them. This gets everyone thinking as soon as possible about execution. And because we’re thinking of overall workflow instead of pure feature development, another rich set of stories soon emerges related to things like quality and testing, release preparation, design and architecture, prototyping, UX design, software packaging, etc. You know, all those things required to get the project ready for customer deployment need to be captured in story-form as well.
In order to do this, I ask the team to place the stories in largely three buckets: opening moves (early stories), middle game (middle – mostly execution based stories) and end game (stories focused towards completion and delivery).
While this is truly not a WBS or Gantt chart, it does serve to get the team organizing the story mix into a rough workflow and begin thinking of linear dependencies and breaking things down for construction and integration. So the flow is illustrated below-
Overloading Your Stories, Meta-Data
Perhaps it’s just me, but if I’m taking time from a team for a story writing workshop, I want to maximize the data that I collect. To do this I usually ask the team to overload their cards with other bits of useful information that I might (keep in mind might) use later. For instance; Adding estimates, in either weeks or story points, can be a useful exercise at this point. This becomes the starting size estimate for each story and even though it’s simply a guess, it does help to communicate size and level of effort across the group.
Another thing to consider is team assignments, especially those for any specialized skills. For example, if there’s a database story that the entire team knows only Sally can effectively handle, then we might say that on the card. Or if the card requires a skill that we don’t currently have on the team, then specifically identify that gap.
I try to avoid any notion of “tasking assignment” at this point, so don’t do this for every story. Just mine these connections as a natural consequence of the writing.
Related to this point is the notion of capturing dependencies and risks. Again, we’re just writing our thoughts down on Post-it Notes, so ask the team to note cross-story dependencies right on the Post-it Notes. You should also visually orient the stories to be “close together” on your board. And while the team is collaborating, I always ask them to identify risks as they go along. I usually maintain them as a growing risk-list off to the side.
I find that this sort of meta-data gathering enhances the quality of the workshop, but also reduces the time it takes for later processing of the stories into a Product Backlog. This data can be equally valuable as the stories themselves.
Finally, What’s Next?
Once I have the “opening move” stories defined, I usually will ask the team to do a bit more detailed expansion around these early stories. The logic goes that while I have your time and attention, why don’t I leverage it a bit more to increase the depth of visibility into high priority stories. This also serves to set the stage for “next steps” immediately following the workshop. So dig into the details on your highest priority stories.
So there you have it! By investing perhaps a half day of time, you can come out of a User Story Brainstorming Workshop with a wealth of information. You have stories. You’ll have a view to workflow, what needs to be done right away, and what’s deferrable. You’ll have a sense for key skill stories and for dependencies and risks. And you’ll have a solid view towards next steps.
But most importantly, your team will have created a “shared view” of their overall project. I’ve found this outcome to be critical when the team starts to iteratively attack the work. Since everyone contributed collaboratively to the overall scope of the project AND contributed to workflow details, they’ll have an innate sense of what is needed and where things are headed.
How cool is that?
Don’t forget to leave your comments below