One of the most difficult things to tackle effectively is taking a client’s dream and producing an application that’s tried and true to their vision. Especially when the project’s requirements are complex, finding a good mode for translating functionality becomes progressively harder. And that’s when the concept of ‘user stories’ fly in to save the day.
What is a User Story
Before user stories were implemented programmers would spend weeks on end writing highly detailed software requirements specifications. “The app shall do this…” and “The app shall do that.” The problem was that no one would ever read them. Clients would not understand them and it’s only natural for programmers to skip diving into a sea of text and get to diving in a sea of code instead.
Instead of paragraph after paragraph of manual-style details, a user story packages the desired feature into one short, structured sentence.
Here’s an example of a user story from one of Messapps very own applications (Reefill):
As a user, I want to retrieve water from the said station once it is unlocked so I can refill my bottle and quench my thirst.
It’s not very detailed, but it does answer three very important questions:
- Who cares about this feature? (the app’s user)
- What is their goal? (to refill their water bottle with water)
- Why do they want it? (so that they can quench their thirst)
Attributes of a good user story
In order to form coherent user stories, as in any profitable pursuit, one should start by INVESTing. INVEST is an acronym (don’t acronyms make life so much easier?) which defines all the attributes required for an articulate user story. The following is each element of the acronym explained:
- Independent
Each user story should be treated as a single component of the whole. Stories should be able to be worked on in any order. Overlap in stories is redundant and confusing. If one is dependent on another, this means that the former was less valuable and could probably be omitted. - Negotiable
A user story is a conversation; details should be co-created with the client and the team of designers and programmers. If they’re both on the same page, scope, priority, and project requirements can be easily changed. And you can bet your last dollar that someone will want to change something down the line. - Valuable
If the story proves to contain no perceptible value delete it; an app is supposed to benefit the user. Every user story should be written with that in mind. - Estimable
A user story has to be sized properly so it could be prioritized correctly. A feature that is high in value but has a lengthy development time may not be the highest priority early due to development time. It may prove more beneficial to complete another feature first. - Small
Stories should generally be small blocks of work. But how small exactly? It really depends; but in the scrum, or in any similar methodology, the user story should be objected in a way that it can be possible for the team to complete it in a sprint, a set period of time which a specific task has to be completed and made ready for review. In agile for example, user stories average 3-4 days of work total. - Testable
A user story is deemed testable if the built product, when tested, fulfills its acceptance criteria. This notion of ‘acceptance criteria’ will be defined and exemplified shortly.
How to Write User Stories
Step 1: Identify who is trying to get the value
User personas describe the types of users your product may have. What this person does is connected to their use of that app. And sometimes an individual may have multiple personas in association with their use of the product.
For example, one can either hail a cab using an application on their phone, but that very same person may very well use the app to connect with potential passengers that are looking for a ride.
Step 2: Determine what each type of user cares about
Once you develop a list of potential users, it’s imperative that you answer the following: What is the user trying the get out of the product? This is the part where you brainstorm a bunch of features.
We can use Messapps app Reefill for example. We can build a user persona with the following features:
- Unlock a water station
- Retrieve water from the aid station
- View personal statistics
- View company-wide statistics
Step 3: Come up with the why and what
The first two parts of each story are now defined: the user type, and their desired goal. Next step is to think about why that type of user wants that feature, or what value it would provide them with.
In accordance with what we came up with in step 2, it should be something like this:
- As a user, I want to unlock a water station using the application so I can retrieve water
- As a user, I want to retrieve water from the said station once it is unlocked so I can refill my bottle and quench my thirst
- As a user, I want to view statistics regarding my past history of retrievals so I know how many plastic bottles I have avoided
- As a user, I want to view statistics regarding the entire Reefill community so I can see how many people are aboard this environment conserving initiative
Step 4: Answer the what and why with the how (Acceptance Criteria)
So you’ve written your story now. But that’s not it. Like every great story, it needs re-examination to make sure it’s logical. You know what you want to do and why it should be done. So now, how do we do it? That’s where acceptance criteria come in. This is where your expertise as a developer or a client with basic knowledge of applications comes in. You’re not traversing far into the innards of an application yet, this will come later, the development stage will take care of this. You’re simply using a bit of imagination to envision how the story will unfold.
Here are some examples from stories presented in the previous step:
- Press an ‘unlock’ button that will send a signal to the water station so it can open
- Present a confirmation gesture that will let the user know they can start retrieving water
- Aggregate the user’s application history and convert it into a statistic
- Aggregate all users history and convert it into a statistic
Conclusion
User stories not only let you form the skeleton of your project, but they also set objectives in a way that’s easy to digest for your team.
These stories do not require a programming degree. These are simple structured sentences that explain wants and needs. A toddler says, “I need to go potty”; an ambitious parent developing a mobile app that potty trains their toddler writes, “As a parent, I want to monitor my child’s toilet training progression,” It’s that simple
Congratulations! You are now ready to create effective user stories that will surely transfer your dream into a reality
Blog Source- https://messapps.com/allcategories/strategy/creating-great-users-stories/
