Over almost ten years of developing digital products and services, we’ve found that our clients benefit from learning more about important processes in Agile development. In this ‘Client’s Guide’ series, we’ll shed light on the main things you should expect to be involved with when working with a digital agency, and why they are beneficial to your project.
In this post, we look at user stories and acceptance criteria, two important (and very closely related) tools in Agile development. We will explore what they are, why we use them, and how you, the client, might find them useful.
What are User Stories?
A user story is a description of a feature that a user will need in a digital service. Most of the time, user stories are written in informal, non-technical language. Crucially, they are written from the perspective of the end-user of the service.
Here’s an example from one of our recent projects with Austrian Alpine Club, a membership organisation:
As you can see, this user story describes one thing which a user, in this case, a member, wants to do with the service – namely, create a password for their online account. (This example is a screenshot from our project’s Trello board – find out more about the tools we use in this blog post.)
The format of a user story is always the same: ‘As a ________, I want to ________, so that I can ________’. Start by naming the user type, then describe the action that they want to be able to take, and then describe why they want to do it or how it will benefit them.
Here’s another example, this time from the perspective of a different user type, the system admin:
Having a simple, plain-language format for user stories means that they are clear and easy-to-understand for anyone who needs to look through them – both for the development and project management team and the client team.
What are Acceptance Criteria?
Acceptance criteria are another Agile development tool, closely related to user stories.
Essentially, acceptance criteria are written guidelines for what a digital service needs to include in order to satisfy its users. You might think that this sounds very similar to how we defined a user story earlier in this post – and it is. The difference is that acceptance criteria relate to the specific features of the service which have already been defined in the user stories. The best way to think about acceptance criteria is that they act as a checklist for each user story. Together, user stories (the features which need to be built) and acceptance criteria (the checklists for building each of these features) give a detailed picture of what a digital service should be like in order to meet user needs.
Here’s an example of a set of acceptance criteria – the criteria here relate to the AAC user story which we looked at above, ‘As a member, I want to create a password on my account, so that I can login’.
The criteria define what the feature (in this case, having a password on the user’s online account) needs to include in order to work well. In this example, the criteria are security requirements that we want the system to have for passwords. We’ve also listed the design work which we’ll need to complete to make sure that the user understands the system’s requirements for a password.
Why do digital projects need user stories and acceptance criteria?
User stories and acceptance criteria are a crucial part of the web and application development process – from ideation through to the technical development stage, these key features and their ‘checklists’ are used by a variety of team members.
Digital projects benefit from having clearly defined user stories, each with a set of acceptance criteria. The process of writing acceptance criteria makes it easy for the team, including the developers and the project manager, to break down a task and scope out how complex it is and how long they expect it to take in design and/or development. Moreover, acceptance criteria provide a quick checklist which a developer can use to ensure that they’ve completed the feature fully.
Acceptance criteria in the form of checklists also make it simple for a project manager, or indeed a client, to quickly appraise a user story and validate whether the requirements have been met. They can then use this information to assess whether or not the overall project is on track.
When it comes to testing a completed digital service, well-written user stories and clear acceptance criteria make the task simple. Whoever is testing the service only needs to refer to a user story’s acceptance criteria to check that the feature fulfils its requirements. And since the criteria were written at the start of the project and used by the team throughout, there’s no reason why they shouldn’t all have been ticked off the list. Clearly defined criteria in the form of a checklist can be especially useful for non-technical team members and clients who want to test features themselves, as they have likely not been heavily involved in the development process.
For project teams like ours, user stories and acceptance criteria are a great way to scope out tasks within a project and monitor progress as they are completed.
For clients, user stories and acceptance criteria are two tools which go a long way towards making the whole development process transparent and accessible.
ARE YOU LOOKING FOR AN AGENCY TO HELP DEVELOP YOUR DIGITAL PRODUCT OR SERVICE? CONTACT MATTHEW, OUR TECHNICAL DIRECTOR, TODAY ON +44 207 125 0160 OR DROP HIM A LINE ON [email protected] FOR A FREE CONSULTATION.
