In our consulting work we often refer to the three C’s of user stories, here is what we mean. The C’s are abbreviations for the:
The card contains little information and is often written in the form “As A <<Role Name>> I want <<a feature>> so that <<some value delivered>>”. There are many different forms that this can take, but what is most important is that what is written, is meaningful to the team delivering the feature and the customer (or product owner) requesting it. Developers cannot write software from the card alone and to that end they need the next part … the conversation.
The conversation is the essence of the requirement and conversations can spawn many outputs or artefacts such as models, notes, story maps or even good old fashioned code! I like to think of the conversation as the most important part of the story because this is where the learning is achieved.
For years as a systems or business analyst I used to write requirements specifications that could sink a small boat and then lob these over the partition to my design colleagues (god I hated conversations with designers – they asked way too many questions ;0) ). But seriously, minimising the written word to specify requirements is important, but you maybe can’t get away with eliminating it altogether.
Conversations, and more importantly evolving conversations, allow the developer/designer to hold the concepts of the requirement in their head while the design and code become the output of a requirements conversation rather than some weighty tome. This minimises ambiguity and uncertainty as the analyst, or better yet customer, can see their thoughts become manifest as a result of a few insightful conversations. Changes can then be made directly as the feedback is received rather than going through some lengthy change management process which will result in a document being changed giving the risk of more ambiguity.
The confirmation (often written on the back of the story card) gives us the high-level criteria against which the resulting feature will be tested against. I like the idea of specifying the system by examples of what the system will do both when it functions correctly or incorrectly. This is a better way of creating a specification as opposed to my boat sinking documentation of yore. Alternatively simple closed questions such as “does the screen go black?” may well suffice for acceptance criteria. But these in themselves will not be the complete set of acceptance tests but only a high level set of tests to give the customer or product owner confidence that the feature that has been created fulfils their criteria of a working feature.