How to Write User Stories in Agile Software Development

Sometimes the idea of writing user stories can seem like another "thing" on top of an already busy workload. But for software development teams who are looking to lead their own improvement and deliver software that works for their customers, writing effective user stories is the first step.

If you’re reading this post, it means you want to learn what will work best for the people who use your software, and improve how you approach software development. That's great! Our goal at Easy Agile is to help you do that.

So let’s start with why good user stories are important.

Why write user stories?

You may wonder why you should write user stories rather than writing features or tasks instead.

If this sounds like you, you might not yet have seen the value of writing user stories, and that they serve a very different purpose to writing features or tasks.

It’s easy to get buried in a cycle of feature development that lacks context. The objective becomes more about clearing your way through a large backlog than building solutions that add value for your customers. To build successful software, you need to focus on the needs of the people who will be using it. Your human customers. User stories bring that context and perspective into the development cycle.

What is a user story?

A user story helps agile software development teams to empathize with their customers. Written from the customer (or user) perspective, user stories help the development team understand what they need to build, and why they need to build it.

User stories are simplified, high-level descriptions of a user’s requirements written from that end user’s perspective. A user story is not a contextless feature, written in “dev” speak.

A User Story = the 'what'

A user story describes a piece of functionality from the point of view of the user.

User stories divide features into business processes.

A task = the 'how'

Tasks are the activities that need to be performed to deliver an outcome.

Tasks are individual pieces of work.

How do we write user stories?

You might like to think of a user story as an ‘equation’:

As a [user] + I want [intent] + so that [value]

Let’s break this down further;

As a [user] — this is the WHO. Who are we building this for? Who is the user?

I want [intention] — this is the WHAT. What are we building? What is the intent?

So that [value] — this is the WHY. Why are we building it? What is the value for the customer?

Let’s look at a few simple examples;

As an internet banking customer

I want to see a rolling balance for my everyday accounts

So that I can keep track of my spending after each transaction is applied

OR

As an administrator

I want to be able to create other administrators for certain projects

So that I can delegate tasks more efficiently

Following this equation, teams should make sure that their user stories are ticking all of the following checkboxes:

To write successful user stories:

• Keep them short
• Keep them simple
• Write from the perspective of the user
• Make the value or benefit of the story clear
• Describe one piece of functionality
• Write user stories as a team
• Use acceptance criteria to show an MVP.

Acceptance Criteria

User stories allow agile teams to balance the needs, wants and values of their customers with the activities they need to accomplish to provide that value.

The link pairing these two things together is acceptance criteria.

Acceptance Criteria or ‘conditions of satisfaction’, provide a detailed scope of user requirements. They help the team understand the value of the user story and help the team know when they can consider something to be done.

Acceptance Criteria Goals

Acceptance criteria should:

• clarify what the team should build before they start work
• ensure a common understanding of the problem or needs of the customer
• help team members know when the story is complete
• help verify the story via automated tests.

Let’s look at an example of a completed user story with acceptance criteria:

As a potential conference attendee, I want to be able to register for the conference online, so that registration is simple and paperless.

Acceptance Criteria:

• Conference Attendance Form
• A user cannot submit a form without filling out all of the mandatory fields (First Name, Last Name, Company Name, Email Address, Position Title, Billing Information)
• Information from the form is stored in the registration database
• Protection against spam is working
• Payment can be made via Paypal, Debit, or Credit Card
• An acknowledgment email is sent to the attendee after submitting the form

With this in mind, teams should make sure that their acceptance criteria considers all of the following:

• Negative scenarios of the functionality
• Functional and non-functional use cases
• Performance concerns and guidelines
• What the system or feature intends to do
• End-to-user flow
• The impact of a user story on other features
• UX concerns

Acceptance criteria should NOT include the following:

• Code review was done
• Non-blocker or major issues
• Performance testing performed
• Acceptance and functional testing done
  

Why?

Your acceptance criteria should not include any of the above, because your team should already have a clear understanding of what your Definition of Done (DoD) includes, for instance:

• unit/integrated testing
• ready for acceptance test
• deployed on demo server
• releasable

Writing effective user stories is a valuable practice that will help you and your team deliver software that stays relevant for your customers.

When you embrace user stories as more than just another task on your checklist, but instead view them as an essential tool for creating context and value for your projects, you can stay connected with your ultimate focus - your customer.