What is a User Story?
Before user stories were implemented developers would go through weeks on end composing exceptionally detailed software requirements specifications. “The app shall do this… “And “The app shall do that.” The issue was that nobody could at any point read them. Clients would not get them and it’s just normal for software engineers to skip jumping into an ocean 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 aid 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
To frame coherent user stories, as in any beneficial pursuit, one should begin by INVESTing. INVEST is an acronym (don’t acronyms make life such a ton simpler?) that characterizes every one of the traits required for an articulate client story. Coming up next is every component of the acronym explained:
Every user story ought to be treated as a solitary part of the entirety. Stories can be worked on in any order. Overlap in stories is repetitive and befuddling. On the off chance that one is dependent on another, this implies that the previous was less significant and could presumably be omitted.
A user story is a conversation; details should be co-made with the customer and the group of designers and developers If they’re both on the same page, scope, priority, and project requirements can be easily changed. Furthermore, you can bet your only remaining dollar that somebody will need to change something down the line.
If the story demonstrates to contain no worth, erase it; an app should profit the client. Each user story ought to be written and composed with that in mind.
A user story must measure appropriately so it very well may be focused on accurately. A feature that is high in esteem however a long improvement time has may not be the most elevated need ahead of schedule because of advancement time. It might demonstrate more beneficial to finish another feature first.
Stories should generally be little squares of work. Yet, how little precisely?
It truly depends; however in the scrum, or any comparable methodology, the user story ought to be objected such that it very well may be feasible for the group to finish it in a run, a set timeframe which a particular errand must be finished and prepared for survey in agile for example, user stories average 3-4 days of work total.
A user story is considered testable if the assembled product, when tested, satisfies its acceptance criteria. This idea of ‘acceptance criteria will be characterized and exemplified without further ado!