The traditional approach to developing a custom website/application/interface is to develop a detailed brief outlining all of your requirements. You hold an internal workshop and brainstorm ideas with your colleagues about what features they want and what they think customers may like. You list out what’s wrong with the current site or platform, including what will make things easier for staff and customers. You end up with a list of items that become the base requirements for the site. The agency prepares a detailed functional specification document that no one else in your organisation wants to read. You read it and sign off on it. You have a large list of requirements and you are confident that the project will meet its goals.
The agency designs and builds the site based upon the requirements. They present it to you for approval/feedback in the User Acceptance Testing (UAT) phase. UAT highlights that the agency did not know enough about your business and there are major gaps in the process and user experience. Feedback pours in from other departments and suddenly you have a contract dispute on your hands and are faced with the inevitable ‘Change Request’ documents. The project goes over budget by 30 percent for you, and likely also for the agency. The process was cumbersome for all involved.
Developing a long list of requirements up front might be good for getting the contract agreed upon, though the assumptions made set up a potential disaster for the user experience. There is simply not enough opportunity to collaborate with all the stakeholders that need to be involved to produce the right outcome for each requirement. The scoping process produces a good basis for legal agreement – that both parties spend the rest of the project defending, rather than focusing on the user (internal or external).
Humans communicate best with each other through relatable and understandable stories.
Agile methodologies provide a different approach to traditional development, through creating user stories. User stories give context for the intention of each requirement/request, providing a different approach to solving the problem. They are created during the project rather than at the start of the project and are ready just in time for development. This ensures that they are relevant at time of writing and are more likely to have input from the key stakeholders whose story it actually is.
Here is a comparison between Stories and Requirements:
A user story is a very high-level definition of a requirement, containing just enough information so that a development team can produce a reasonable estimate of the effort to implement it.
What are user stories?
A user story:
- describes a piece of functionality from the point of view of the user
- allows team members to understand both user and business benefits
- underpins all the work an Agile team needs to do - user stories are the basis of plans, development and testing
- evolves through conversations with the client.
A story generates a conversation, while a requirement is to establish a legal contract for a fixed price and outcome. Understanding the value of the story to the user can provide a complete picture of what is being developed and why. This change in context can provide a completely different understanding of the actual use of the function, which can then produce a completely different outcome.
The context shift comes from focusing on the user rather than the business requirement. The story is defined just before development starts, rather than at the time of briefing or contract negotiations. This allows the business and the agency to focus intently on the needs of the user at that time. It also means that input from other stakeholders can be sought at time of defining the story, creating interest and involvement in the project without a major investment of time.
Format of a user story
The format of a story is deliberately simple. It uses plain language to convey an understanding of how the feature will actually be used. The story is a single sentence plus acceptance criteria. The Product Owner is encouraged to write the user story as they have the most knowledge about what is needed and why. They can consult other stakeholders within the business and can run it past the team. However, the end result is something that they have written, understand and have ownership of. This is critical as it means that they can easily identify whether what they asked for matches what was developed.
User Story Tips
- Focus on providing clarity about your product features
- the what, not the how
- Stay high-level - keep it simple and solid
- Understand the users
- Think as a user - understand the underlying needs and the expected value
- As a (type of user)
- I want to (take this action)
- so that (I get this benefit)
Example of a user story:
- As a credit card holder
- I want to view my statement (or account) balance
- so that I can pay the balance due
Characteristics of a user story
- The story should be self-contained, in such a way that there is no inherent dependency on another story.
- Stories are not explicit contracts and should leave space for discussion.
- A story must deliver value to the stakeholders.
- You must always be able to estimate the size of a story.
- Stories should be small enough to be able to plan/task/prioritise with a reasonable level of accuracy.
- The story or its related description must provide the necessary information to make test-driven development possible.
How does the team and the Product Owner know that the intention of the story will be fulfilled? By defining what success looks like upfront. Success of the story is defined as the acceptance criteria, which outlines how a particular feature could be used from an end user’s perspective. It focuses on business value, establishes the boundary of the feature’s scope and guides development. These are unique to each user story and establish the conditions for the success of the feature.
Acceptance criteria could establish a boundary that helps team members to understand what’s included and what’s excluded from the scope of the user story. The criterion of user story acceptance not only informs the product behaviour in happy path scenarios, it also guides the user experience when things don’t work as intended. It describes what would be verified by the acceptance tests.
When the Product Owner verifies a particular user story acceptance criteria and the developed feature passes it, the development of the user story is considered a success. Pass/fail type results allow acceptance criteria to form the basis of creating tests that can be automated and executed.
Acceptance Criteria Tips
- Each user story should have at least one acceptance criterion.
- Acceptance criteria are written before implementation.
- Each acceptance criterion is independently testable.
- Each acceptance criterion must have a clear pass/fail result.
- Focus on the end result (not the solution).
- Include functional criteria, such as login form or search box, as well as non-functional criteria, such as requirements around page load speed or meeting AA accessibility standards, when relevant.
- Team members discuss acceptance criteria during backlog refinement so the Product Owner can verify them. This confirms the Product Owner and the team have a shared understanding of the user story.
Creating acceptance criteria
Acceptance criteria should:
- define how a particular feature could be used from an end user’s perspective
- allow someone to understand the value of the story and set expectations as to when a team should consider something ‘done’
- establish the conditions for the success and release to the users and stakeholders
- clarify what the team should build before they start work
- ensure everyone has a common understanding of the problem/need of the customer.
Example of a story with acceptance criteria
- As a credit card holder
- I want to view my statement (or account) balance
- so that I can pay the balance due.
- Display statement balance upon authentication. Eg: $2560
- Display total balance. Eg: $4560. Here, the balance due from the current period is $2560 and past balance due is $2000.
- Show minimum payment due. Eg: $140
- Show payment due date. Eg: 19th of the current month
- System displays within 5 seconds of receiving the request
- Show error message if service times out or is not responding
Features are documented as the detailed information is uncovered by the team together with the Product Owner. Having a requirement for ‘campaign landing pages’ in the original scope document generally provides little information about what is actually needed. The development rarely matches expectations.
Unlike the scope document (functional specification), by documenting the features as you go, the information matches what has been built and why. Rarely does a scope document match the final product, as the requirements uncovered during the project change the scope of the project, meaning the scope document becomes irrelevant.
Stories communicate so much more than traditional requirements lists, endearing the team to your vision and giving them a context for what they are doing.
‘As a Marketing Manager I want to be able to create campaign landing pages whenever I want so that I can maximise my advertising budget and increase conversion.’ This sentence raises many questions about what might be in the landing page and how it will be used. During sprint planning, the team can ask these questions and the answers can form the basis of the acceptance criteria. For example, acceptance criteria for campaign landing pages could be:
- A hero image
- A benefit statement
- A large call to action visible when the page loads
- A link for more information
- The option of a video or text-based testimonial
- With all of the above do they need to be configurable? e.g. Can I have a landing page with a CTA and another one without, or do I always have to have a CTA?
- Tracking success of the landing page in Google Analytics
As humans, we relate far better to stories about why we need something than descriptive requirements of the requested output. Understanding the story of how something will be used broadens our thinking beyond simply trying to satisfy the details of the requirement.
Consider this story. As a parent, I want to buy a birthday cake that doesn’t contain any nuts to protect my daughter who can have a severe allergic reaction to nuts and be hospitalised.
This story (and acceptance criteria) is far more likely to get your attention. And it provides a different reaction to the traditional approach of listing requirements such as ‘we need the ability to filter cakes’ on the bakery’s new website. The change in context means that the team may come up with an additional solution that was not previously considered. For example, providing the ability to exclude all cakes with nuts from search results and/or automatically add an icon to each product image that shows which cakes have nuts. This saves time and money, while improving the user’s experience and possibly creating a repeat customer.
Stories allow us to be more creative with solving a problem. As we look at the problem/challenge from the user’s perspective rather than simply trying to meet the requirement that the business listed in its brief. By focusing on the user stories of the end customer, it provides the user with a far better experience as it is tailored to their situation. You may end up solving more problems than what were originally stated.
When you solve people’s problems by understanding their story, you create happy customers who come back again and again. Which is ultimately the aim of every marketer and every business.
This post is the second in a series on Agile ways of working. See Part One: Agile ways of working with distributed teams.
Want to tap into the expertise of an agency that’s been in operation since 1999?Get in touch
Want more? Here are some other blog posts you might be interested in.