Introduction
Working with our clients, we frequently get asked about how a perfect user story should look like in order to facilitate the cooperation between business and development teams. Below is a small write up on the subject based on our longtime experience.
User stories are central element to the agile/scrum methodology as they define every piece of work being done by an agile team. There are several important guidelines that needs to be followed to create proper user stories that fit well with the overall process.
Components of user story
The user story is an expectation about the system expressed from the point of view of the end user. The crucial elements of the story are:
- The role of the user in the system that is going to benefit from the system
- The short description of what the goal or intent of the user is
- The specific business value/benefit that we expect to achieve by implementing the user story
The user in the first point does not necessarily need to be the end user of the application itself. It is the user that is going to benefit from the change. In can also be an admin or even a person from the development team.
The business value statement will allow the team to focus on the big picture business expectation instead of specific system functionality. This allows the development teams to come up with creative ideas and not to go off the rails while executing the story.
In addition to the elements mentioned above, a user story should contain acceptance criteria, which are high level test criteria that confirm that the story works as expected. The acceptance criteria can be both functional and non-functional. Please note that this does not need to be full suite of tests for the feature – this is going to be developed by the agile team during the implementation.
Examples
- As a site visitor I can create a new account so that I can get personalized experience on my next visit
- As an admin I can create a new user group so that I can assign permissions to the user faster
A user story should be small enough to be executed within one sprint. If the team believes that the user story is too large it needs to be split. The reason is that in agile methodology the work is being delivered incrementally in sprints, which are allotted time slots of team’s work. Each sprint should result in delivery of business value as defined by the user stories included in the sprint.
How to organize stories?
To enable better management of large user stories there were additional story types introduced: enablers, spikes and epics. An enabler is a story that is not delivering business value at the end of the sprint. Instead, it enables the team to deliver the value in the subsequent sprints, building on top of the outcome of enabler story. Also, the work related to system architecture, refactoring can be captured as an enabler.
The enabler stories should not be overused though: the strength of the agile process is in rapid delivery of the business value and feedback from the actual users. A series of enablers followed by a single user story that brings them to the user would be contrary to the purpose.
A spike is a research or investigation work that needs to be performed to properly design or estimate an approach or user story. The purpose of this story is to reduce the risk or uncertainty related to use of specific technology, estimation of a user story or a functional scope. Spike might also include building a small prototype.
Also, the user stories can be organized into epics, which are larger initiatives that group individual user stories, spikes and enablers related to particular business area.
+1 (888)
413 3806