User stories are an essential part of a software development. Each user story depicts something significant about requirements of the user from the user’s perspective. And similar to any good storyteller, you need your stories to be precise and meaningful.
Why create user stories?
To focus on the user
User stories encourage the team to concentrate on tasks that are appropriate, and a compilation of stories keeps the team directed on resolving problems for real users.
To facilitate collaboration
With the end goal established, the team can work collectively to determine the best way to assist the user and adhere to requirements while achieving the end goal.
To drive creative solutions
Stories boost the team’s creativity to think about critical factors to achieve the end goal in the best possible way.
To create momentum
With each achieved story, the development team relishes a small challenge and a small success, encouraging momentum.
How to discover the right user stories?
It is very important for the project to cover the right user stories. By right user stories, I mean the stories should be completely relevant to the user’s needs. Redundancy and requirements out of the scope should be avoided.
The right user stories can be achieved with:
User personas serve to capture insights concerning the users and their personalities. Personas involve fictional characters and combine details like a name and a photograph; related characteristics, behaviors, and perspectives; and a goal.
Here is an example of a user persona:
(image source: Interaction Design Foundation)
The goal of the persona is to illustrate the problem that the user is encountering. This helps to build the right user stories by understanding the functionalities that the user expects.
User stories are created based on input received from discussions between customers, organizations, and end users. Users elicit their challenges and expectations, which are framed into user stories. User stories also should be a collaborative endeavor amongst management and the development team. This helps to decrease overhead and expedites delivery with the necessary information. It also leverages the creativity and expertise of the team, which results in better user stories.
An epic is a skeletal user story that is typically split into numerous user stories over time by accumulating the user feedback on initial prototypes and product increments. It resembles a title and a placeholder for more detailed stories. Epics enable outlining the product functionality without committing to the details. This is especially convenient for describing new products and features. It permits you to capture the estimated scope and buys time to understand the best ways to address the users’ needs.
Epics are broken into smaller, detailed stories until they are clear, feasible, and testable. All development team members should have an understanding of the story’s significance. The story should not be too huge and should easily fit into a sprint. There has to be an efficient method to resolve the completeness of the story.
What are the components of a user story?
A common problem with user stories is with providing the right quantity of detail.
As explained by Bob Hartman in “Making Agile a Reality”, good user stories can be created when you INVEST in them. Hartman explains that the acronym, and the concept behind it, involves:
- Independent – User stories need to be independent in order to facilitate correct prioritization. Dependencies may hinder an implementation by introducing less valuable stories just to make a more valuable story possible.
- Negotiable – User stories should be a result of collaborative negotiations between the customers, end users, product owners and business analysts, as well as development and testing teams. The goal of the user story should always meet the needs of the customers and end users.
- Valuable – User stories should hold business value.
- Estimable – Accurate prioritization of stories requires proper estimation. If the estimated story has too many story points and lengthy development time, the best practice is to split the larger user story into smaller pieces and then estimate them accordingly.
- Small – As per Agile methodology, user stories should not be too lengthy and written in a manner that requires 3-4 working days on an average in two-week sprints.
- Testable – Every user story should be testable and include required acceptance criteria that should meet the requirements of the story. The user story can be considered as ‘DONE’ only if all of the acceptance criteria is tested and meets the requirements.
Including too much detail in a user story makes the story writing process consume more time. Also, it could slow the development as tasks like design, coding, and testing do not commence until the details have been added. In turn, it delays the team and its product owner to get feedback from users and stakeholders.
On the other hand, including little detail can lead to the team struggling to completely implement a story through a sprint as they spend excessive amount of time exploring answers.
But how do you determine how much is the right amount?
A user story should include the following:
Who is the user?
The user story must depict who is requesting the value to be addressed. In a sense, who is the user who needs the feature? The feature must focus particularly on the user who requires it.
Thus, a user story begins with: As a [user]….
Where [user] is the name of the user in question.
Example: As an iPhone User…
This may appear simplistic, but it’s important that the user is recognizable by the development team, so that they can place themselves in the user’s shoes and mindset when contemplating the soundest way to deliver value.
What does the user want to achieve?
This is the next part of the user story, which represents the requirement of the user. Common blunders that story writers make is incorporating the solution of the user’s problem in this section. Story writers must have the skill to work with users and avoid diving to solutions when capturing their requirements. By doing this, the best path to value delivery could be restricted.
The user story proceeds: As a [user], I want to [achieve this]….
Example: As an iPhone User, I want to share photos on social media…
What value is delivered by achieving the user’s requirement?
The team must understand the value that is expected to be delivered with every requirement. A value statement presents a clear idea about the priority of the task. Without the value statement, the team will be unable to justify the reason they are doing the work in the first place.
Here’s is the structure of a user story with its value:
As a [user], I want to [achieve this]…so that [value]…
Example: As an iPhone User, I want to share photos on social media so that I can network with my contacts
What is the acceptance criteria of the story?
Acceptance Criteria is the checklist of requirements that need to be developed to accomplish the user’s goal. They give more detail about the user’s goal. Only after all the acceptance criteria are satisfied, we can then say that the user’s goal is achieved.
These narratives reveal the requirements in a specific manner to describe the user’s needs, using the format: “Given”, “When”, and “Then”.
Given: I have the “Share” option available on my iPhone
When: I click “Share” on the desired photo
Then: The iPhone should enlist the various social media websites where I would like to share the photo
The acceptance criteria can be recorded as bulleted points or numbered lists.
(image source: Easy Agile)
Here is an example:
As an iPhone user, I want to send multiple photos in a text message, so that I can network with my friends
- I can share the desired photos via text message
- I can share photos with multiple contact numbers simultaneously
- I can add a text message along with attachments
- I can select up to 10 photos stored on my phone
- I can share multiple photos at the same time
- I can share the photos in less than 1 second per photo
The acceptance criteria should be crisp and clear. If the list contains a lot of criteria, the user story becomes too complicated and needs to be broken down into shorter stories.
What is the pictorial representation of the requirement?
The pictorial representation of the requirement comprises of the mockups or the wireframes of the requirement. This method of blending wireframes into Agile user stories enables the development team to easily understand the requirements.
There’s no doubt that developers need detail in user stories. Mockups are important because, as Leon Barnard at Balsamiq.com explains, they can provide 80% of the information with only 20% of the effort of a more interactive or pixel-perfect tool to create the wireframes.
When the team develops new screens or web pages, it’s essential for them to know the way you envision the look and feel of the user interface. Wireframes are a conventional technique to generate a low-fidelity layout that is used as a guide by the software engineers.
Usually, functional user stories include the mockups and wireframes. Technical user stories that involve the description of backend code, databases, etc. may not need wireframes to be attached to the story.
Workflow diagrams are also a very efficient way to represent the flow of users’ steps and actions. When we work on stories or use cases where data “moves” or travels, it is especially good practice to have diagrams.
Workflow diagrams represent details of more targeted flows (for example, when we’re figuring out the feature for sharing pictures on an iPhone). We will create a workflow diagram outlining how this process will travel, such as this:
Unlock phone -> Click Photos -> Click desired album -> Click desired photo -> Click Share icon -> Click desired social media icon -> Click Send
Non-functional requirements are not about specific functionality but are rather about an attribute or characteristic of the system. Some examples include: reliability, availability, portability, scalability, usability, maintainability, security, performance, robustness and so on. Fortunately, non-functional requirements can be easily handled as user stories.
Below are metrics for measuring the non-functional requirements:
(image source: Altexsoft)
- As a customer, I want to be able to run your product on all versions of Internet Explorer
- As a client, I want this system to perform adequately with 100,000 concurrent users
There is always a chance that the technical/non-functional stories frequently get side-tracked in favor of more engaging user-centric features. If these requirements are kept till the end of the development phase, then this may nullify the benefit of early identifications of the non-functional requirements and the benefits that accrue from early development.
When following the above process and components of creating successful user stories, the software development process becomes much more efficient and streamlined. Your product is for the user. Therefore, your product’s success hinges on its user stories. So, take time in writing your stories and your product will be great!