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, debugging, and maintaining them – yet, I found I was still not communicating with my customer or my development team very well. Quality didn’t improve. We still were at risk of building the wrong product.
Agile User Stories are a placeholder for conversation. I think that’s what I like the most about them. Conversations – especially face to face – are the best way humans transfer information between each other. The amount of information that humans can transfer between each other during a face to face meeting (something I call a “High Bandwidth” or “High Fidelity” meeting) is absolutely stunning. The further away we get from face to face, the more effort it takes to truly communicate and convey intention – and, more importantly, the more effort is required to receive this communication and its intentions. Communicating, using only documentation means that we need to put a HUGE effort into the documentation effort – both in the production of the document and the consumption of the document. For example, I’m sure I could have described this entire blog post in 5 minutes to you if we were having coffee at a Starbucks – however, it will take me much longer than 5 minutes to write this post – and it may take you longer to consume this post and the meaning and intent behind it. This is what I call “low bandwidth” or “low fidelity” communication. To me it’s like trying to talk through a straw.
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 center allows me to better understand and represent the value the system is attempting to provide.
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 want displayed on the screen once the record is fetched? This is the discussion part!!! We try to use High Bandwidth communication to have this conversation with our customers and our developers to make sure there is a deep understanding what “done” needs to look like.
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 structure for these as well.
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.