Where do User Stories Come From? Part 1.
An Approach for Generating User Stories
I see many agile Product Owners struggle with backlogs on their own for new projects. Quite often they insist on personally owning the backlog-which equates to authoring every story themselves. While this approach certainly works, it does require a lot of additional vetting time with their teams-bringing them up to speed on the story content. So it can be time intensive and a bit wasteful.
In his book User Stories Applied, author Mike Cohn discussed the notion of User Story Writing Workshops. These are collaborative, whole-team events where you spend time writing a set of stories to instantiate a product backlog for a new project or for any large chunk of new work. From my perspective, these look very much like traditional JAD Sessions — if you are familiar with those.
I see way too much individualized story writing and too little group-based activity, so I wanted to spend some time in my next two posts discussing the dynamics and merits of User Story Writing Workshops.
Getting a Facilitator
One of the most critical success factors in the workshop is finding or declaring a facilitator. This is best served by someone with facilitative training and experience, someone who is also a bit removed from your project-perhaps from another organization or team. The more independent they are, with little to no context in your project, the better the job they’ll be able to perform.
If you can’t get someone who’s independent, then go for facilitative experience. If you can’t find that, then perhaps engage a Scrum Master or someone with a similar background. The key point is to not try this yourself, but rather go get some experienced help. Someone who’s full-time job in the workshop will be facilitating the team dynamics and driving the outcomes of the workshop.
The first thing the facilitator will do is coordinate workshop logistics.
You’ll need to invite your entire team to the workshop. While you’re at it, invite the central business stakeholders and customers-as many as you can since you’ll want to get a mix of perspectives. Make sure you schedule the workshop at a time when everyone is available. Beyond that, ensure they commit to attending and actively participating. The earlier you begin setting expectations, the better. So check-in with each of them explaining how important their role is and discussing any unique contributions you need them to make.
Beyond finding a solid facilitator, another key to meeting success is preparation. You’ll need to sit down with your facilitator and “game plan” the meeting. First up is the sort of documentation or presentations needed to give attendees a sense for the vision and scope of the project. Sometimes good old fashioned requirement artifacts do that. Other times, a focused slide deck will do. In still others, a high level project charter is shared.
Ensure that you spend some time thinking of how you’ll “Set the Stage” for the workshop and who will be best to do that. Sometimes it will be a team of folks and quite often, most of their presentation materials already exist. They just might need some reformatting.
You’ll need Post-it notes, markers, flip charts, white boards, etc. for the physical meeting. The more the merrier. I prefer different color notes to represent that various perspectives-green for the business, yellow for quality, blue for development, and pink for key stakeholders. This way, you get a quick visual representation of perspective as you order the stories.
The room should easily accommodate your group, with the potential for “break out” areas for smaller sub-team discussions. For example, the quality and test folks might want to break out on their own and discuss test-driven stories, and the overall workflow for the effort.
And finally, you’ll need to pull this all together in an agenda that will drive the workshop. I like to think in terms of the following steps:
Brainstorm Roles First
I highly recommend brainstorming application roles before diving in and writing your stories. Roles help to bound your brainstorming steps and focus your team on specific areas of responsibilities. And don’t think of roles as simply human-centered or user- centered. You can and should create a broad spectrum of the key roles that will be driving and using your application.
Roles can surround physical users: normal user, super user, administrative user, secure user, stakeholders / the boss user, etc. They can also include malicious users, for example: hacker user, disgruntled ex-employee user, criminal intent user, etc.
Non-physical user roles can be equally interesting to define. They might include some of the following: system AP’s, outside vendor data feeds, external databases, business processes, regulatory processes, periodic events, quality activities, etc.
As a general rule, you’ll want between four and10 roles within your story mix. Less is fine, but more will probably become unwieldy. You can fairly easily consolidate roles if you have too many; just ask your team how to condense them.
I hope this initial post was useful in setting the stage and beginning your User Story Writing Workshop. I also hope I convinced you of how important planning and preparation are to a successful workshop. In my next post, we’ll get into the details of writing, organizing, and ordering the story results. I’ll also show you how additional meta-data points can be derived from simply writing stories as a team. See you then…
Don’t forget to leave your comments below