I like agile user stories. They make sense to me. 15 years ago – I wrote a lot of “Use Cases”. As use cases seemed to have some components I liked – they frightened and intimidated me - I found that as use cases would gradually become more complicated and cumbersome to write – I spent all my time writing,
Agile User Stories are a placeholder for
User Stories also stress a few other things that I like (as with others such as Mike Cohn). A good user story has good structure. User Stories should highlight the Role/People/Personas involved in the story, what their goal is, and what the expected result should look like. This was also something I really liked about Use Cases – we called them Actors – which allowed me to “define” and “see” the system from the perspective of each of the Actors in the system. Making the Actor/Persona/User/Role (whatever you want to call them) front and
Here is an example of a simple user story:
As a Customer Support Representative
I want to lookup up customer information based on the customer telephone numbers
so that I can quickly see customer history information when talking with customers on the phone
Not surprisingly, there are lots of other things you’ll need to know before you start writing code. Where do you get the customer phone number? Does it pop up on the computer? Do you ask the customer? What kind of customer information does the CSR
Where do the results of this conversation go? In fact, what we focused on during our conversation is what “done” means – so, this becomes our target. I like to represent the answers to these questions as Acceptance Criteria for the User Story – a more explicit way of saying “according to our conversation, this is what success looks like”. As with a User Story – I like to have
Given <precondition>
And <precondition>
When <action>
And <action>
Then <expected result>
And <expected result>
Here is a simple example:
Given the customer provides their telephone number to the CSR
When the CSR enters the telephone number into the Customer Search screen
And the customer has a record in the system with the corresponding phone number
Then the system will display the customer name, address, and a list of history of customer activities
What’s great about capturing the results of our conversations in this way is that we now have an explicit memory of the conversation we had (face it.. sometimes the best of us forget or make up memories) – and, more importantly, we have a way to agree to the meaning of “done” – as we can pass/fail these acceptance criteria very easily. In fact, if you really like Behavior Driven Development and Test Driven Development – having these acceptance criteria defined as they are is a great way to govern and drive your development efforts as your development team can now work to explicitly satisfy these criteria.
Joel Semeniuk is a Microsoft Regional Director and MVP Microsoft ALM. You can follow him on twitter @JoelSemeniuk.