User stories are a short description of characteristics and properties of the system expressed as user needs. They are used in product development processes as a part of Agile methodology to identify functions and obtain quality for the user. User Stories are an effect of cooperation between clients who identify the requirements and the vision of the product and the project team who aggregate and verify information. Such communication enables the unification of the vision, solutions and desired effect as well as it minimizes the risk of potential errors.
The most common scheme features:
As a client of an online shop I want to be able to register my own profile because I don’t want to fill out the data every time.
As a user of a portal I want to be able to adjust the access level to my profile for the people I don’t know, because I want to protect my privacy.
As an advertiser I want to be able to edit the budget during the campaign because I want to react to changes quickly.
The scheme above enables a clear identification of who, what and why does a given activity, therefore we see not only the functions but also their weight and relevance to the entire system. The need to work with usability in mind makes it possible to organize work, taking business objectives into account. User stories most commonly describe one chosen interaction between the user and the system. Despite its seeming simplicity it is easy to miss scheme components or misidentify the level of detail. To prevent that, it is a good practice to follow the rules of creating user stories as presented in the following scheme:
Each story should define acceptance criteria including: which parameters should be fulfilled for the story to be accepted (logging in through Facebook, e-mail or LinkedIn are acceptance criteria for logging function). Checking particular criteria for a given story is expressed via a test scenario which identifies what must be tested and what functions should work. Definition of done, on the other hand, answers the question what parameters mean the given user story has been finished. Finishing a story means finishing a spring at the same time.
User stories at the brainstorming stage are usually written down on sticky notes which restricts the space and enables a better focus on the nature of the described activity. All stories form a collection of backlog and are developed by a team in subsequent iterations in JIRA tool.
The most common errors made are:
Time estimation of the iteration is possible due to creating Story Points which identify the relative size relating the stories against each other. A point doesn’t identify the absolute unit in time. It means that choosing the simplest task and assigning the value of 2, we assume that a task of describing 4 will take twice as much time. The points reflect the workload, not the time needed.
Due to that the differences resulting from resources, skills or attempts cease to constitute a discrepancy. The same task is done by two different teams with a different pace, therefore it is necessary to take into account the workload and team efficiency.
Well-written user stories contribute to structuring teamwork and saving time on implementing ideas. User stories take advantage of the synergy effect resulting from a common developing of the best possible effect. Therefore, this methodology, known as agile, is used on a daily basis by companies developing software.