After you have collected and prioritize your product’s list of features, you need to break them down into smaller, more manageable chunks. These smaller items will form the base of what your team will build. It is important for you to think about all of the different things a user might do under that feature.
For example, one of your features is that you want users to Sign In to your app. That seems simple enough but there could be a lot of components to signing into an app. You can:
- Let users enter a user name and password
- Check if the user name and password match an existing account
- Check if the user is logging into a recognized device
- Send a two-factor authentication code to complete log-in
- Let users reset their password if they forgot it
- Redirect first time users to a Sign-Up/Create Account process
- Alert users of account authentication failure
- Apply access restrictions after a number of failed attempts.
There are many more ideas that could be built into this single feature of “signing in”.
After breaking down your ideas, you should begin to write them into a format called a user story. A user story is a sentence that describes what a user want to do and why they want to do it.
A user story has the following structure:
As a <role>, I want <requirement> so that <reason>.
Within this single sentence is nearly everything your Scrum team would want to know about the idea they are building.
First, they can see the role of the person performing the action. This helps clarify who is needs this requirement. Is it a first-time user or an existing client? Different users types will have different needs so the role is very important.
Additionally, the role is important because your users should be your number one focus. Building what they want will lead you to a successful product.
Second is the requirement that is being designed and built. This is what your user wants to do. It should be self-evident why this is a critical part of the user story.
The last part is the reason. My Scrum teams find it useful to have context behind a requirement. As a product owner, you know the value and the business interests but the rest of the team might not. Adding the reasons helps your team gain insight into why you and the user want the requirement built.
Here’s some examples of user stories I have recently written for my main product, a reporting portal for my company’s business partners.
- As a <user>, I want <to view a Contact Us page> so that <I can easily find key details about Answer Financial>.
- As a <user sorting columns by a date>, I want <the information to sort in chronological order> so that <I can easily see the oldest or newest items>.
- As an <account manager>, I want <to add Answer’s newest release schedule> so that <users can view the schedule>.
As you can see, these simple sentences help the development team understand what our users want from our portal.