This lecture focuses on creating user-stories at epic, feature and theme level with focus on the structure, design and implementation of writing clear agile requirements.
Big Picture
Agile Requirements
Gathering requirements is often based on big design up-front and mapping out the requirements early during the feasibility and analysis design process. In Agile the requirements emerge closer to the emerging detail and in terms of fitting into the fixed time boxes or sprints the clarity and concise nature of requirements are so important. User-Stories are enablers for this process.
The objectives of user-stories is focused on:
Remove ambiguities
Improve quality
Alignment towards business benefits
Speeds delivery
Delivers clear outcomes
User-stories are clear and prescriptive in structure and is based on rigid and concise terminology. It is this approach that provides clarity to its audience. They are easy to read and translate for a business and developer and add transparency to the often blind journey.
Hierarchy of Requirements
A user-story is part of a hierarchy, it sits just above the acceptance criteria's and beneath an epic. So why do we start here? This is probably because this is the lowest part where we can prioritise and derive value. However, it would be really difficult to make sense of the evolving detail, hence the hierarchy allows the structure we need to understand where we are and where we want to get to.
The Theme is the focus or the goal to be achieved. The theme can be driven by product iteration(s) or the entire length of the product development.
At Epic level - we can group the user-stories; generally if a user-story cannot be completed in a single sprint it is packaged as an epic. A feature is more specific in a set of functionality that delivers business value. Grouping epics/user-story under a feature provides clarity in the functionality to be created and helps to understand the dependency of any other features.
A user-story is part of a hierarchy, it sits just above the acceptance criteria's and beneath an epic. So why do we start here? This is probably because this is the lowest part where we can prioritise and derive value. However, it would be really difficult to make sense of the evolving detail, hence the hierarchy allows the structure we need to understand where we are and where we want to get to.
1. User Story
A User-story is a conversation, it is structured in a very simple natural language and has a set structure. It is customer driven, where the outcome and impact is understood as part of a conversation between two people.
Card, Conversation and Confirmation
3 C's Card, Conversation and Confirmation are the components for a user-story. It is imperative that the process starts and ends with an conversation and there is an confirmation or agreement on the outcome. User-stories have traditionally been written by Business Analysts - but can be written by customers, stakeholders, developers almost anyone.
From an Agile perspective user-stories need to be concise and light in order to develop them iteratively. The emerging details appear during the Sprint, So high level or start-up stories are written at high level. This is too ensure we have the flexibility in design and approach. All the detail will be revealed at the right time.
Behavioural Driven Development (BDD)
The most commonly used for for a user story is the 'As a ... I want ... So that' structure.
It is a really simple and effective way to relay un-ambiguous requirements from the customer to the delivery. The emphasis is to capture the what, how and outcome for a requirement. The format is quite straight forward:
As A <Role>
I want <to complete an action>
So that <We can apply some benefit>
Example 1
As A Engineer
I want to Update the latest software
So that we are compliant with the latest version.
Example 2
As A Database Developer
I want to set all blank dates to system dates
So that every field contains a value.
Having the right user-story will really help particularly when splitting user-stories in to a Sprint. The art for user-stories is to have the right granular level for the detail that is emerging. Having too much information will make the requirement ambiguous and sometimes complex to understand.
In terms of delivering a user story setting an Acceptance Criteria (AC) to deliver successful delivery to the agreed customer expectations is an important structure to any user stories. This forms the two parts of a User-story on a card or post-it, the front the actual story and the back of the user-story is the Acceptance Criteria
Acceptance Criteria
The objective for an acceptance criteria (AC) is to complete a user-story expectation that is to be delivered and tested upon. The AC gives a user stories the agreed bounderies for succesfull delivery .
An acceptance criteria is used to validates a user-story ensuring the actual behaviour of the feature is the expected behaviour from the perspective of the customer. A well tested acceptance criteria improves the quality of the feature. In Agile a Behavioural Driven Development (BDD) approach is used in the form of scenario based GIVEN - WHEN - THEN format. The format of a acceptance criteria is shown below:
GIVEN <Context>
WHEN <Action>
THEN <Result>
Example 1
GIVEN THE TOTAL TAX EARNED BUTTON
WHEN WE MULTIPLY THE TOTAL BALANCE * TAX RATE
THEN THE TAX PAID IS SHOWN WITH NO ERRORS.
Example 2
GIVEN FOR INSTALLATION OF APPLICATION
WHEN I SET THE PERPETUAL LICENSE FLAG TO YES
THEN SOFTWARE IS COMPLIANT TO AGREED LICENSE PLAN.
Example 3
The INVEST MODEL
The INVEST mneumonic was first developed by Bill Wake in 2003. It is a good guide or recommendation on how a user-story should be structured. The main points are illustrated below:
A user-story should be Independent. It needs to be stand-alone and have not be dependent on other stories, normally user-stories are broken down further in order to get into more detail and lower the estimate on the delvery. However, grouping similar dependent user-stories into a single user story is more practical.
User-story is negotiable, it is not set agreed terms as the detail for the feature is emerging and can potentially be changed. The Agile principles states
"...Welcoming changing requirements, even late in development. Agile processes harness change for the customers competitive advantage..."
User-stories should be created if they have either business or economic value. They are not a wish-list but a clear and concise representation of the business or technical needs of the feature. They should be written in simple language this would result in less ambiguity in its representation.
Stories need to have clarity in its detail. It should be simple to understand so simple to estimate. Using common language is important to reduce the complexity in the detail. User-stories should not contain detailed description, this can be done at a higher epic level.
Its important for user-stories to be small and manageable within scope to be delivered within a single sprint. By splitting stories into smaller manageable units will allow them to be delivered more efficiently.
Clarity in what is to be tested within a user-story is important when clarifying the delivery for a user-story , the assumption for a user story cannot be tested may imply the story may not be clear.
2. Epic level
If a user-story cannot be delivered into a single sprint then it is captured under an epic. Often epics are confused to suggest they are an umbrella for user-stories, but its real use is to manage these stories in order to commit and deliver them into single sprints.
Large user-stories are very good candidates for epics, the user-stories are broken down in to smaller user-stories or story-splitting to ensure these are deliverable into the sprint.
Each user-story is grouped into a single epic and each associated story within an epic is related in terms of delivering the component or epic level.
Epics are useful for positioning or documenting a user-story in terms of capturing not only the user-story but also the business case for such a requirement. A group of epics can also be captured as a Feature.
3. Feature
A Feature quite simply is a component or function for a piece of requirement that enables the organisation to do something. The most simplest use-case is to take an on-line ordering website, the main features are:
- Add Order
- Edit Order
- Remove Order
Each of these features hae a clear and overall function and objective, and the sum of parts make up the bigger picture and deliver clear business value.
4. Theme
A Theme allows an agile organisation to group its features and epics into a group that is associated to a common goal or objective. This theme often can span several areas and its commonality amongst the features drive its goals. Themes sit above the feature level.