A few months ago I agreed to fill the role of acting Scrum master so I could try out some new techniques with the team.  One of the things I've been itching to try is utilizing user stories as the basis for a Product backlog.  I got the idea from a few of Mike Cohn's articles on his site, as well as his book which I highly recommend.  It seemed like a fantastic idea, for several reasons:

1. User stories are feature-centric and not implementation-centric.  That is, they describe a feature from a particular user role.  I firmly believe the Product backlog should be kept feature-centric as well, for reasons I may expound on some other time.
2. User stories are expressed in "business" language.  This makes them very easy for sponsors to understand, discuss, and even create.  It also helps keep the conversation focused on the value the story brings to the project.
3. User stores are simple and relatively terse.  Each one fits on a single index card.  That makes them very amenable to centralized backlog management tools, like Tackle.
4. User stories easily adapt as the understanding of the business need changes.  This is exactly what the Product backlog should do.
5. User stories are estimate-able and independent, just as a Product backlog entry should be.

Now, I should point out that I had never actually written or used user stories before, I've just read about them and heard anecdotes from my peers.  They've always seemed like a better approach to what I've experienced, which is the massive requirements collection that reads like home theater assembly instructions and is dated the moment it's written down so even with 80 pages of spec I need to walk over to the product owner to get questions answered.

The target project was an integration project with some new features on an established product.  There had been some ... adjustments ... in staffing and people were having to fill new roles.  There was a lot of confusion about how to drive the project and where to start.  In short, a perfect time to try something new...

Cutting Teeth in a StoryStorm

I had the customer representative, the product owner, and some members of the team commit to a four-hour storystorming session.  The basic idea is to get a bunch of people in a room for a timeboxed session where everyone cranks out as many stories as they can; the goal is breadth, not depth.

One person on the team had some exposure to user stories at another company, so I asked her to spend 15 minutes or so describing the concept to everyone.  I emphasized Mike Cohn's wisdom about phrasing each story from a specific user role, expressing a specific business feature and it's value to the user.  We discussed how the pile of note cards would become the product backlog for the project.  We walked through developing some example stories that were relevant to the project.  Everyone understood the process and thought it would produce a usable backlog.  So I passed out index cards and pens, set my egg timer for 5 minutes, and asked everyone to write as many stories as they could think of.

And they froze.  The ticking of the egg timer was deafening amidst the occasional tap of a pen on the table, the crackle of an index card being sacrificed to the Ultimate Outbox.  No one was writing a single thing.

After a few minutes I realized my mistake - it was completely unreasonable for me to expect the team to be comfortable cut loose on an open-form task they had never tried before.  They were afraid, and rightfully so.  They were filling new roles on a new project that was very different from the norm in a company that recently had lay offs.  I quickly thought back through the basics:

Software requirements are a communication problem.  User stories are one way of addressing that problem; each story is a placeholder for a conversation between the developers, testers, and stakeholders. 

So I killed the timer and suggested that we start talking.  We had already made a list of every user role in the project during the overview; to provide direction to the conversation I picked a single user role and we started discussions with the first thing that user would have to do to use the product.  It took some time to feel out how to hone the discussion into user stories, but following Mike's phrasing template was invaluable to accomplishing this.  After a while the index cards were getting pumped out faster than I could keep track of them, and the process started to feel natural and comfortable.

We finished that first session and did a mini-retrospective on the process.  The general consensus was positive, although some team members opted to withhold their joy until they see the project features implemented.  We scheduled several more sessions over the next week to round out the backlog.  Some sessions were spent standing in front of the product, actively modeling the user activities while a scribe jotted down the stories.  Overall, it seemed to be a very effective and productive way to produce the project requirements.

Little did I know that I had made several mistakes that would nearly derail the project...

... which I'll discuss in pt 2: the Kickoff that Didn't.