the ‘bee log

Recently our team has switched to user stories as a means of capturing requirements. Our first “story workshop” happened today and it was a real success. We wrote around 80 good stories for a new project we’re starting in a month or so. What suprised me most is that everyone (even non-technicals) latched onto it right away. I did find that I had to remind people not to express stories in terms of the software they are currently using (as we are replacing it) and, especially, to avoid expressing stories as negatives (a user cannot…). When you’re replacing a system you can just leave the negatives out.

(Mike Cohn’s User Stories Applied is good stuff. Highly recommended.)

A little background: we’ve been using a slightly modified form of Scrum for around a year in a small, six-person development shop. In the beginning we tried a 30-day sprint as recommended, but changed the length to three weeks in an attempt to get management buy-in on a control cycle. I work from my office in NYC and the rest of the developers are based in Syracuse, NY.

Our first pass at capturing requirements was a homebrew technique that used short bullet points with IETF RFC-2119 keywords. The tendency there was to express things in terms of the technical tasks required to implement a project. For one reason or another, things broke down and we slipped into the “oral tradition” of capturing and communication. Hard to pull everything of the top one’s head when asked to provide an update on project status.

When we started using Scrum, we used an excel workbook to track our backlog and sprint. Again, things were expressed in very technical terms. Great for the developers, but difficult for stakeholders to get a handle on where things are and what value we’re bringing to the table.

An attempt to use Use Cases never got off the ground (overkill for our purposes).

I’m looking to user stories for a couple of things:

1. Help make our reports more meaningful to the customer team by expressing progress in terms of business value.
2. As we break down user stories into the various technical tasks, ways of introducing inter-dependence between team members Up the collaboration factor and leverage the team dynamic with our developers!
3. User stories are (relatively) easy to capture (and therefore keep going as a process) and leverage spoken communication.