As Gojko Adzic is currently drafting his book titled Fifty Quick Ideas to Improve your User Stories, I picked up the following useful tips from his latest draft:

1. Card-Conversation-Confirmation – The book assumes that readers are familiar with the concept of “Card-Conversation-Confirmation” (see Fig. 1 below) and the “INVEST” model (see Fig. 2 below). Both assumptions made me revisit the related concepts in more detail. I then also brushed up on ways to split user stories in such a way that they are ‘workable’ and as clear and as small as possible (see Fig. 3 below).
2. Describe a behaviour change – Gojko makes the point that often it can be insufficient to just describe someone’s existing behaviour, and that it can be more beneficial to described a desired behaviour change instead. This trick is particularly useful with user stories that have an overly generic value statement, or where the value statement is missing. I created a simple example in Fig. 4 below. I guess the main thing here is to make sure that there’s a clear user outcome which can be tested. In my below example, the main acceptance criterion would be: “Can I see the top 5 reviews?”
3. The scenario should consist of a Given, an Event and an outcome – When describing a behaviour change or a scenario, the following elements should be included: a Given (some context), an Event (‘when I do this’) and an outcome (‘then this happens’). In addition, I like adding a sentence to outline the ‘so what’ of a certain outcome, describing the intended benefit to the user.
4. Describe the system change – In order to achieve the aforementioned behaviour change, the story should also be clear about the change the team needs in order to accommodate the desired change in user behaviour. What does the system need to do to enable the change in user behaviour? For instance, following my example in Fig. 4 below; if we want to enable users to filter products based on product scores, then we will need to create the necessary functionality in the system to enable this filtering behaviour (see Fig. 5 below).
5. Watch out for generic roles – In his book, Gojko makes the point that it’s important to be as specific as possible when it comes to defining the “user” who is the ‘beneficiary’ of the story outcome. He argues that “without considering a particular user segment, it’s impossible to decide whether the proposed solution is the right one, or if it’s just unnecessary scope creep.”
6. Put a ‘best before date’ on the story – When working in an iterative and flexible fashion, dealing with time-constrained changes can be a big challenge. I therefore like Gojko’s suggestion to put a date in specific stories that are subject to a deadline or which need to be completed before other stories can be started.
7. Set deadlines for addressing major risks – We all know how tempting it can be to go for implementing the least complex user stories first and to hold off on delivering the more complex or riskier stories. However, I firmly believe it’s important to focus on the riskiest stories first, because – as Gojko points out – if you don’t address the risky stuff, at the some point the ceiling will come crashing down. He therefore suggests setting clear deadlines for dealing with specific, major risks.
8. Group stories by impact – Gojko builds on his previous book about Impact Mapping by suggesting to incorporate user stories into the relevant parts of an impact map. An impact map is a visualisation (mind map) of how deliverable scope connects to business goals and the underlying assumptions on four levels. An Impact Map typically consists of these four levels: (1) business goal for a milestone of a project or a product delivery (2) user segments, stakeholders or actors who will be involved in achieving the goal (3) the impacts on users and stakeholders that can contribute to the business goal, or that could hinder achieving the objective and (4) the deliverables – user stories or even larger deliverables (such as epics) that can cause the impacts.

Main learning point: Even if you think that you know all there is to know about user stories, I still recommend you read “Fifty Quick Ideas to Improve your User Stories” by Gojko Adzic. Not only does the book provide a lot of helpful tips on how to create a user story but also offers valuable advice on how to fully incorporate user stories in planning processes. I found the book – based on its latest draft – to be a very valuable resource when it comes to learning how to create and apply user stories more effectively.

Fig. 1 – “Card, Conversation, Confirmation”, as defined by Ron Jeffries – Taken from: http://guide.agilealliance.org/guide/threecs.html

“Card, Conversation, Confirmation”; this formula (from Ron Jeffries) captures the components of a User Story:

• A “Card” (or often a Post-It note), a physical token giving tangible and durable form to what would otherwise only be an abstraction:
• A “conversation” taking place at different time and places during a project between the various people concerned by a given feature of a software product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation;
• The “confirmation”, finally, the more formal the better, that the objectives the conversation revolved around have been reached.

Fig. 2 – INVEST as way to summarise characteristics of a good user story, as defined by Bill Wake – Taken from: http://en.wikipedia.org/wiki/INVEST_(mnemonic)

• Independent – The user story should be self-contained, in a way that there is no inherent dependency on another user story.
• Negotiable – User stories, up until they are part of an iteration, can always be changed and rewritten.
• Valuable – A user story must deliver value to the end user.
• Estimable – You must always be able to estimate the size of a user story.
• Small – User stories should not be so big as to become impossible to plan/task/prioritise with a certain level of certainty.
• Testable – The user story or its related description must provide the necessary information to make test development possible.

Fig. 3 – Patterns for splitting user stories by Richard Lawrence – Taken from: http://www.agileforall.com/2009/10/patterns-for-splitting-user-stories/

1. Workflow Steps – It can work well to build the simple end-to-end workflow first and then add the middle steps and special cases.
2. Business Rule Variations – Allow for several different business rules, each of which can be a good story on its own.
3. Major Effort – Split user stories by the amount of effort or complexity involved. For example, create an “epic” user stories, with ‘smaller’ but related user stories hanging off it.
4. Simple / Complex – As soon as you feel that a user story is getting too big or too complex, come up with some initial acceptance criteria to start breaking down the big story into smaller stories, splitting off variations.
5. Variations in Data – When you don’t know the data variations upfront, the best thing to start with the simplest version first. You can start with a ‘good enough’ version first an then add more stories just-in-time after building the simplest version. Naturally, this can be different when you know the data variations up-front.
6. Data Entry Methods – Complexity sometimes is in the user interface rather than in the functionality itself. In that case, split the story to build it with the simplest possible UI and then build the more usable or fancier UI.
7. Defer Performance – The focus of the initial product or feature might be to just make it work, and not worry to much about scaling or a fast performance. You can come up stories for these aspect at a later stage.
8. Operations – Sometimes you end up with stories that incorporate multiple operations or interactions. For example, a story about user account management can include creating, edit and cancelling an account. It can be worthwhile splitting these different operations into separate stories.
9. Break Out a Spike – A story may be large not because it’s necessarily complex, but because the implementation is poorly understood. In this case, no amount of talking about the business part of the story will allow you to break it up. Do a time-boxed spike first to resolve uncertainty around the implementation. If you’re not sure about how to implement a story, the related story can read something like “Investigate how to ___” and the related acceptance criteria can be the specific questions that you want answers on.

Fig. 4 – A simple example of a user story and acceptance criteria, outlining a desired behaviour change