A User Story template for event-driven users

Posted by Robert Merrill on December 1, 2008 under Business Analysis and Requirements | Be the First to Comment

Modern software development processes are moving away from legal-document-style “the system shall” requirements to less formal User Stories. Further, software users and buyers are encouraged to write user stories themselves. If they’re used to being interviewed by a business analyst and then being handed requirements to review, this can rattle them at first.

I often have to show them what I mean by User Stories, and I use a template I think I got from Mike Cohn’s User Stories Applied (It’s a great book, even if it’s not where I got the template):

As a ______, I can ________ so that ________.

For example,

As a telemarketer, I can see the customer’s last three orders, including returns, so that I don’t offer them what they already have, or worse yet, what they bought and sent back.

But I’ve also done enough requirements workshop facilitation to know that when you ask a different way, you get a different (and often valuable) perspective that would have otherwise gone missed. Not the end of the world on a well-run agile project, but it’s still beneficial to get as many of the stories as you can to start with.

To really get subject-matter experts thinking business and not systems, I’m starting to use this variant:

As a ________, when ________, I can ___________ so that ____________.

If you first have the group create a list of business events, you can use those to drive another round of story writing. Suppose we identify an event “my shift ends.” That might remind people of another story:

As a telemarketer, when my shift ends, I can review my call statistics and add notes for my supervisor, so s/he knows about any extenuating circumstances I encountered, and I still get the credit I should.

The next time you’re helping people get started with user stories, try the event-driven variant. You and they may both like it. And check out this other template for non-functional requirements.