User Stories

My team is doing an experiment with user stories; I’m currently gathering requirements for a global licensing module to support multiple applications and regions in my company, and for that project, all goals and customer requirements are being written in the user story format.

User stories are loosely defined as a concise explanation of a need, the person with the need, and the objective that can be achieved by meeting the need. This provides context that a simple “The system shall…” statement cannot. On the other hand, because of the “As a ____, I need ____ so _____” format, user stories are conducive to wordiness. One suggestion to mitigate this risk is to write them initially on index cards–presumably if you’ve filled up the card, you know you’ve written enough or too much.

As for what to write on the card, following the format makes it relatively clear–however, analysis still needs to be applied so that the “I need _____” is completed with the “what,” rather than the “how.” I find it difficult sometimes to step out of the “how,” and sometimes find more “how” than I like to admit when I read old requirements, but the less of it, the better!

An idea that’s new to me is the acceptance story; this is a template that allows the analyst to designate how a requirement shall be deemed satisfied, with the following syntax:

Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…

This may be cumbersome to write for each requirement/story in a requirements document; my first thought, without having tried to implement these, is to write them for selected user stories only–presumably, those that could benefit from additional clarification. Any thoughts?

~ by John Peltier, M.S. on October 25, 2008.