How to build User Stories?
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 – person, adjusted role,
- I want – quality, functionality, activity,
- because – justification, result, benefit.
User Stories examples:
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:
- Independent – building mini units which can function independently from others and be developed in free order,
- Negotiable – developing stories in a team as a result of discussion and cooperation with a client,
- Valuable – essential for the end user, important for business,
- Estimable – easy to estimate in terms of workload,
- Small – small enough to plan and develop an iteration, possible to develop from a few days to about two weeks,
- Testable – identifying acceptance criteria, building test scenarios and conditions of their success.
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.
Most common errors in user stories:
The most common errors made are:
- too much detail – it distracts the team and its attention and creates a risk of missing an important part of a conversion
- too much generics – creates problems with extracting functions in a given iteration
- too much formality – distracts from the user and lessens the readability of the description
- using technical parameters masked in user stories – listing technical tasks instead of user history contributes to blurring the task prioritizing
- skipping the discussion stage – it becomes a risk to maintaining the correct direction of the project and skipping functions that are essential for the user
Pros and cons of using user stories
Pros of using user stories:
- unification of the vision and communication language between a client and a team
- prioritizing functions
- maximization of usability
- boosting creativity level through cooperation
- facilitating time estimation of particular iterations
Cons of using user stories:
- complications in the description of purely systemic tasks, e.g. bugs, spikes
- discrepancy in the approach to the functioning of a given story between a client and a developer team
- lack of information concerning the method of development and design interface – differences between developers
- focusing on business functionalities and missing the technical ones, e.g. Server’s efficiency
- losing control of the whole vision resulting from functionality fragmentation
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 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.