Identifying User Stories and Deriving Acceptance Criteria

Most Product Owners I have met do not have a method for identifying candidate user stories or deriving acceptance criteria for those stories.

CAVEAT: I believe you should only model to the level of detail needed, regardless of what type of model you are using. If the team were building a process to allow employees to claim back business expenses, I would not spend a lot of time modelling the process because the process itself is unlikely to be complex. However, I have never worked on a project where the processes were not complex and I have found that it is the process models themselves that tell you what your candidate user stories are (although not all of them will come from process models). This blog post is in the context of complex business operations.

I have been on a few projects now where the Product Owners were new to the concept of user stories. In some cases, the POs received no training at all prior to taking up their role and had no Agile Coach to guide them.

My experience is that when the user story is the only technique available to POs and BAs, avoidable misunderstandings always come to light during playbacks, testing and even in production. Yes, I know Agile is meant to allow you to quickly iterate and enhance but that is too often used as an excuse not to do any analysis or planning.

User stories do not exist in isolation from one another. When user stories are plucked out of conversations with users about complex business operations instead of being derived from models of those operations, you can be left with a jigsaw puzzle instead of a picture of those operations. Yes, you can put the picture together from the pieces but the whole idea of a puzzle is that it is meant to be difficult and take you a long time. Who wants to build business operations and software like that?

This “puzzle” approach leads to some or all of the following problems:

• Not identifying all the user stories
• Identifying some wrong ones
• Not fully understanding how the user stories relate to each other
• User stories that negatively impact each other (one user not knowing or caring about another user’s needs)
• User stories that do not support the strategic goals of the business or, worse, contradict those goals
• User stories being written from the PO’s or BA’s perspective (“As a BA…”) instead of the business perspective
• User stories missing the value statement (“So that…”) – missing because it was not understood or, worse, the user story added no value to the business
  
• Missing acceptance criteria
• Incorrect acceptance criteria

The way a real jigsaw puzzle is produced is analogous to the approach you should be taking: you have the picture first and then you break it up into pieces (user stories). The only difference is that understanding where each piece fits should subsequently be easy, not puzzling.

My approach is like that. You make a picture (it can be a simple sketch or a life-like oil painting, depending on the need) and you use the picture to decide what pieces you need. Whenever someone needs to know the context of any particular piece, they hold it up against the picture. End of analogy.

Here is my approach, in brief:
<collaborate>

1. Consider each atomic task in a business process model draft as a candidate for a user story. This won’t always be the cause, as some tasks can be grouped into a single user story:
   • The label of the lane in which the task appears often (not always, sometimes the task beneficiary is not the task performer) gives you the “As a…” clause.
   • The label of the task becomes the “I need” statement.
   • The business value that you documented as meta-information about the task (I hope you did that) becomes the “So that…” statement.
2. Based on how the process flows within your model, draft test scenarios:
   • Your test scenario will cover several atomic tasks and so several user stories.
   • Use a phrase such as “Verify that…” for each test point in your scenario.
3. Draft the training material (if you’re required to do so).
4. Amend the process model if the test scenarios and training material reveal flaws.
5. Each “Verify that…” phrase becomes a candidate acceptance criterion in your candidate user story.
6. Iterate.

</ collaborate>

A certain amount of this work needs to be done before any software development project starts, otherwise you have no initial Product Backlog. You don’t wait until the models, scenarios and user stories are perfect and complete because they are never perfect and complete. However, you need to get them to a state where they are good enough to act as a foundation for the current project and as a baseline for future enhancements.

Anyway, that is my method. It is not the method but it works for me and it is certainly better than no method.

Do you have another method that works?

Kind regards,

Declan Chellar

The copyright of this blog post belongs to me, Declan Chellar, you may not reproduce any part of it without my written permission.