The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.

I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.

The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:

Agile Requirements Snail

Iteratively Refining Requirements

From my experience the details of the requirements emerge in roughly this order:

1. Feature
   • Name
   • Size [Optional]
   • Priority
2. User Story
   • Name
   • “As <user role> I want to <action> so that <goal>”
   • Conditions of Satisfaction [Optional]
3. Scenario
   • Name
   • “Given <precondition> When <trigger> Then <result>”

The requirements are successively refined. They start as course features, which are split into small user stories, and end up as fine grained test scenarios. But even within each of those levels some aspects of the requirements come before others. The name of the feature comes before the size, priority and associated user stories. The name of the user story comes before the formal format (“As a …”) and conditions of satisfaction. The scenarios come last but even here the names of the scenarios usually come before the formal format (“Given …”).

Feature

Remembering that the cards on the board are just a reminder to have a conversation you can go a long way with just the name on the Feature card. The names should be short and snappy and instantly recognisable, for example “Search for Customer”.

Feature Card: Search For Customers

I use the term “Feature” here but in the XP and Scrum world “Epic” has general currency. I prefer the term “Feature” and the more refined version a Minimum Releasable Feature as labelling something an “Epic” just means it is big. In contrast a “Feature” and MRF are different to a user story and are managed in a different way.

It is the Features that populate my release plan. If I do need a development schedule – and some people don’t- then I will get an estimate on each Feature. For the last few years I’ve been using T-Shirt sizes (Small, Medium, Large) but Story Points are also good.

The last bit of data on a Feature is the priority of the item. I don’t record the priority on the card, which is why you don’t see one on the example. The priority is obvious from the where the Feature appears on the wall / product backlog.

Note: the number in the top left is just an unique ID. I have a habit of putting IDs on everything. So people can talk about Ticket #42 or the Feature “Search for Customer”.

User Story

I display the user story’s name prominently on the card on the board. As with Features, the names should be short and snappy and instantly recognisable. I find the name of the user story it much better as a reminder for the conversation than the formal format (“As a …”). The formal format is terribly verbose and as the only thing on the card obscures the core intent. The user story names are the labels in daily currency, e.g. somebody might ask “What is happening with Search by Name?” but is very unlikely to ask “What is happening with As a help desk operator I want to search for my customers by their first and last names so that customer response times remain short?”

User Story Card: Search by Name

People often put conditions of satisfaction on the back of user story card. I view the conditions of satisfaction as optional because they are quickly replaced by the scenarios. If conditions of satisfaction are listed they tend to be “happy path” scenarios.

User Story Card: Conditions of Satisfaction

Scenarios

Scenarios are the core of Specification by Example and Cucumber. In a “3 Amigos” style of meeting the product owner (and/or business analyst), developer and tester brain storm the names of the scenarios. You need all three perspectives to guarantee a full range of scenarios, both happy and unhappy paths. For example:

Feature: Search by Name
	
As a help desk operator 
I want to search for my customers by their first and last names 
so that customer response times remain short
	
Scenario: Combination of first and last name
Scenario: First name only
Scenario: Last name only 
Scenario: Hyphenated names
Scenario: Blank name
Scenario: Special characters only

The next step is to flesh out the scenarios with the formal format: “Given <precondition> When <trigger> Then <result>”. This might happen at the 3 Amigos meeting or after the meeting as homework by one of the team (typically the business analyst). The scenarios literally add specific examples to the spec.

Scenario: Hyphenated names
  Given these customers: 
    | First Name | Last Name        |
    | Barry      | White            |
    | Thomas     | Burt             |
    | Bob        | Griffiths        |
    | Amanda     | Thomas-Griffiths |
  When I search for Last Name of "Thomas-Giffiths"
  Then search returns "1" customer with the name "Amanda Thomas-Griffiths"

What started as a fairly high level requirement, “Search for Customer”, has ended up as a set of very detailed and specific test scenarios, with the user stories as a kind of middle ground.