The beginner’s advanced guide to building an app
By: A Osman
Tags: Mobile App Development, Software Development, Product Management, Apps, Agile

Writing User Stories

The first step is to write good user stories; this makes their categorization and tracking easier. To write good user stories, we use the ‘INVEST’ method.

Until you get the hang of writing user stories, you can confirm each story fits the criteria below.

Independent

✅ As a new user I want to sign up

An independent story is not tied to other stories. The ‘sign up’ feature can be built first thing, in the middle, or the end of the project. It doesn’t depend on any other story being completed, and vice versa. It does have relationships with other stories, such as logging in. But you can build the login functionality before the sign up functionality if you really wanted to.

❌ As a new user, I want to sign up and view available services

This story on the other hand, forces two separate parts of the system, authentication and services, to be developed together. That creates an unnecessary coupling, and can be split into two or more independent stories.

Negotiable

✅ As a customer, I would like to see available dates.

A user story is not a contract, but more of an invitation to conversation and collaboration. It captures what needs to be done, not how. For example, a user who is booking an appointment would want to see available times, but how this is done is left up for discussion when the time arrives to work on it.

❌ As a customer, I want to be able to get a popup of available dates.

By saying it has to be a popup, that creates a contract for the developer to abide by. Now that you’ve told the developer how to do something, later you may notice that in fact, popups are annoying and unnecessary for this feature. It can be displayed right under the date. Leave the details out, and just focus on the action or journey the user is taking.

Valuable

❌ As a user, I want to update my profile pic.

A user story should reflect something important. One of the stories we ultimately ended up ditching for the MVP was adding a profile pic. For an appointment booking app, the user will be the only one to see their own profile so it was not important for the first version. It added no value , but took away time from developing more important features identified in our user flows. It was added to the ‘Nice to have’ pile in case it made sense later.

Estimable

✅ As a customer, I want to see available openings by date

We prefer to have our stories take 5–10 hours to develop. This story was originally estimated in our project for 5 hours and was done in 3. Estimates get more accurate the more stories you complete as you learn how fast you are capable of going. If we cannot assign an estimate, we break down the story into simpler tasks or make it clearer.

Small

❌ As a customer, I want to book an appointment

Just by looking at that story, it’s obvious this will take much longer than 10 hours. The booking system can be complex, so we break them down into smaller features, that can be tested on their own, such as:

As a new user, I want to view available services

As a returning customer, I want to see available times

As a customer, I want to update my booked appointments

Testable

✅ As a customer, I want to be able to see available openings by date.

To ensure we could appropriately mark each story as ‘Done’ once it’s developed, they need to be testable. For each story, we attach ‘Acceptance Criteria’, and the developer writes automated tests to ensure it always does what’s expected. If these criteria are met, we would consider a feature tested and Done.

Sample Acceptance Criteria for this story could be:

Selecting a valid date returns appointment times

Appointment times returned are actually available (I.e. not booked by someone else or blocked off)

Appointment times are within the business hours

❌ As a customer, I want to know where to tap to get available openings

We can’t write a user story that will place us in the mind of a customer. You can never know what the customer knows, so this would be something handled through the UI/UX design of the app (upcoming blog post).