I’m not really sure if you would consider this user story example to be good, bad or indifferent – I guess it depends what you’re used to – but here is an example nevertheless!
This is the front of the card.
The Card section describes the user story. The Conversation section provides more information about the feature.
Note the feature (for a user to log in to a web site) is small, so the story can be fairly well described on a small card.
Clearly it’s not as detailed as a traditional specification, but annotating a visual representation of a small feature at a time, makes it fairly self explanatory for team members.
And I would certainly argue it’s more easily digestable than a lengthy specification, especially for business colleagues.
Here is the back of the card:
Whether or not these are the right scenarios, or cover all possible scenarios, isn’t really the point of this example.
The point is that the test cases for this feature are written on the back of the card, in support of the information about the feature, and before the feature is developed.
Generally speaking, there is a very fine line between a requirements scenario and a test case, so it isn’t necessary to capture too much detail on the front of the card and clutter it up. The card in its entirety represents the requirements for the feature; whether captured in the Conversation section or the Confirmation section.
Even the description of the user story in the Card section carries some important information. In this case, there is a pre-condition (the user must be registered) and a post-condition (the user can access subscriber-only content). All of the card must be read to get the whole story.
Importantly, the User Story is expressed in business language, and in a micro, more easily digestable, information-packed format.