This blog post will explain what Agile Requirements are, and guide you through writing and using User Stories.
What are Agile Requirements?
As we cannot possibly know all requirements of our products at their inception, it is futile to spend time creating a detailed Requirements Specification Document upfront. Instead, we should use Agile Requirements.
Agile Requirements are requirements that are allowed to, in fact encouraged, to evolve over the lifetime of a product. We are learning more and more about our product during its development through feedback from Customers, Users, Stakeholders and Developers. Using this feedback, we can regularly choose to add requirements, remove requirements, add more details to requirements, change their priority, and so on, to make sure our Agile requirements will deliver the most value to the business as soon as possible.
Agile requirements are typically held in a ‘Product Backlog’, or a ‘Requirements Specification List’. Whatever you call it, it is simply a list of work to do.
An initial Product Backlog should contain several high-level requirements, big requirements. These high-level requirements are sometimes known as Epics.
The Delivery Team, together with the Product Owner, should throughout the development of the product continually ‘Refine’ the Product Backlog. Refinement is a process of ordering, sizing, and breaking down the most important requirements, so that they are ready just in time for development.
We aim to have roughly the following two to four weeks of work refined, so that it will be ready for delivery. We do not spend too much time refining lower priority requirements for a couple of reasons:
- We might never get to these requirements, so it would be wasted time and effort.
- We might learn something in the higher priority requirements which might impact those lower priority items.
On the Product Backlog, the requirements themselves are often represented as User Stories. User stories describe the business problem, business need, or the ‘what’ that the business wants to achieve.
Writing User Stories
Writing a user story is not just another way of creating a detailed requirements specification, or an Agile method for the sake of one. User story writing supports the different way of working needed for Agile requirements.
User story writing is normally/usually undertaken during the refinement meeting. It is a team collaboration effort - everyone should be involved in story writing. This collaboration is essential to make sure everyone in the team understands what a specific requirement means.
This is a massive improvement on the traditional Agile requirements specification document passed to the team, which is then expected to interpret the requirements. User story writing is a key enabler for good communication between delivery team members, the delivery and the business.
The User Story Format
User stories are written in a specific format:
As a <who>
I want <what>
So that <why>
This format is the most common format, and, while there are others, this is the most often used one. It allows us to consider three important things about the requirement:
- Who is it for
- What is it
- Why is it needed.
Who is the end user of this requirement? Answering this question helps the team understand who they are developing the requirement for. The team may make different decisions on how to deliver a requirement depending on Who has asked for it.
What is the requirement or business problem we are trying to solve? This is obviously essential for the team to understand.
Why is the requirement needed, what value is it adding, what benefit is it expected to achieve? Answering the ‘why’ helps give the Delivery Team and the Product Owner information to make an informed prioritisation of the requirement.
The 3 C’s for user story writing
For guidance on user story writing, we can use the 3 C’s: Card, Conversation, and Confirmation - each of them describes an important element for a user story.
The Card refers to the fact that user stories are traditionally written on an index card. There are several reasons for this:
- The card has a limited amount of space to write on. If there is too much information on the card, then it’s a sign that the user story needs to be split into two smaller user stories.
- It is a physical card which can be passed to someone who can look at it, read it, comment on it and pass it back. Physical cards can be easily organised in a sequence of priority or sizing.
The conversation is, as I said earlier, a critical part of the collaboration on a user story. If you have someone writing user stories for the team in isolation, then they are missing the point of user story writing. The collaboration is lost.
The regular, ongoing refinement of the requirements is essential to their collaboration and evolution.
The confirmation is the final part of a user story. The reverse side of the index card is used to identify the Acceptance Criteria. The Acceptance Criteria tell the team what the customer or Product Owner will be guiding themselves by in order to accept the requirement as complete.
Now that we know what a user story needs to contain, and how to write it, let’s look at how we can tell if it is ready, or refined enough for development.
‘INVEST’ is a good way to check that your user story is ready for development, and is often used by teams in a ‘Definition of Ready’. During refinement, the Delivery Team should be asking themselves: ‘Are the user stories for the next period of work ready for development?’, or are they INVEST-ed? Let’s check out what the acronym stands for.
Interdependencies between user stories complicate prioritisation, estimating and planning. Hence we want our user stories to be independent from one another by the time they are refined enough for development. This allows them to be developed in any order. Having said that, some interdependencies may be inevitable.
We want our user stories to be Negotiable, and negotiated through the collaborative refinement meetings.
A User Story is not an explicit contract for features, it is a token for the conversation in the refinement stage, during which the story will be split and refined. Over time, a user story may acquire notes that may be recorded in refinement meetings, for example: UX diagrams, to-be process flows, models, test ideas etc. These will be attached to the user story to add more context.
Every user story should be contributing some value to the Business. Otherwise, why would we do it? The value could consist of value for the customer, user, or purchaser. The Value could also be an intangible value; for example if we implement system X, we can improve our development process to be more efficient going forward.
The bigger the user story, the more difficult it is to estimate. Through refinement we split user stories down into smaller ones, and the estimates will become more and more accurate.
There needs to be enough information about the user story for the team to be more accurate with their estimates. Again the information is gathered by the Delivery Team during Refinement meetings.
If a user story cannot be estimated, it should be split into a (time-boxed) ‘Spike Story’ for investigation, so that it can enable a good estimate, followed by the rest of the user story to implement the feature.
Small enough or Sized appropriately
A user story needs to be Small enough to take into development. A guideline is that the story should require 1-5 days of effort to complete. This will allow the team to complete it in a short amount of time, and get feedback on it sooner.
Finally, we want the user story to be Testable. Through refinement, the Delivery Team need to have gained enough information about the requirement to be able to understand its needs, develop it and execute tests.
User stories carry an implicit promise of "I understand what I want well enough that I could write tests for it".
So, what are Agile Requirements?
- Define the requirements, the business needs, or ‘what’ the business wants.
- Start out as high-level requirements and are refined over time to be ready for delivery.
- Are ordered or prioritised, so that the requirements that deliver the most business value are done first.
- Higher priority requirements have time and effort spent on their refining so that they are ready for delivery.
- Time is not wasted on refining lower priority requirements until just before they are due to be delivered.
- Encourage collaboration and communication within the Delivery Team, and between the Business and Delivery Team.
- Help target small increments of business value from which the Business and Delivery Team can learn what customers use or don’t use, like or dislike.
This should give you a good foundation for Agile Requirements and User Story Writing, helping you to outline your requirements in a clear, efficient and effective way.