Telling Stories With User Stories
Updated: Sep 25, 2020
Have you ever struggled to articulate the vision for the future state while working on a change initiative? If so, was it in part because you didn't have all of the information or have a good understanding of all of the business context? For many business analysis practitioners this is a common challenge when trying to enable change. An effective way to overcome this challenge is to leverage persona-based and narrative-based modelling techniques that when executed correctly are as effective and as efficient any other techniques. With the growing need to rapidly deliver value to stakeholders, traditional methods of eliciting and specifying requirements have been usurped by easier to execute techniques such as user stories.
What Are User Stories?
A user story is a persona-based modelling technique that describes the needs of a specific stakeholder group and the value to be realized through the need. User stories are usually documented as short narratives consisting of 1-2 sentences that describe a stakeholder’s role in a business context, a need that they have, and a goal or objective that they are trying to accomplish through fulfilling the need. User stories are typically documented using the following format:
As a <insert user role> I <describe the need> so that I <describe the goal or objective >
Let’s examine each component of a user story in more detail.
User Roles
The first component of a user story is the user group who has the need articulated by the story. The subject of a user story should be a class or group of users who interact with a solution to accomplish something. Articulating the needs of groups of users makes it easier to identify missing requirements and ensures that a solution is designed to satisfy all the different functions that it will be required to serve. Consider the following example:
As an inventory clerk I <<need something>> so that I can <<accomplish something>>
In the example above, the story describe the specific needs and objectives of an inventory clerk. These needs contrast the needs of other potential user groups such as a payroll clerk, or accounting clerk who may also be users of the solution.
Needs
The second component of a user story is the need. Needs in the context of a user story may represent features, functions, qualities or characteristics required to be present in a solution that is being designed, built and implemented as part of a change. For simplicity sake, a single user story should articulate only one need. User stories can be abstracted across all domains and at all levels of detail. In the context of systems or software development, the needs articulated in a story may represent features or functionality required to be able to perform a task or function. Consider the following example:
As an inventory clerk, I need to be notified every time an order is placed so that I can <<accomplish something>>
In a business context, a need may be anything required that serves a legitimate business purpose at any level of abstraction. Consider the following example:
As a business owner, I need timely access to sales data so that I can <<accomplish something>>
Goals or Objectives
The last component of a user story is the goal or objective that the user is trying to accomplish. The goal or objective is important because it serves as the rationale or justification for the need. It clearly explains why the need is important and what value it will deliver to the user. This is also important because it serves as the basis for prioritization through comparing the relative value to be delivered and the significance of the needs across multiple stories. Consider the following example:
As an inventory clerk, I need to be notified every time an order is placed so that I can fulfill the order in a timely manner.
In the example above, an inventory clerk needs to be notified every time an order is placed so that they can perform one of the core elements of their job function, order fulfillment. Consider the business-oriented example:
As a business owner, I need timely access to sales data so that I can develop sales promotions.
In the business oriented example above, a business owner needs access to sales data to be able establish promotions.
Benefits of User Stories
The following is a summary of the key benefits of user stories:
They are easy to understand and to explain to stakeholders. Stakeholders and business analysis practitioners do not require any specialized knowledge or subject matter expertise to create user stories.
They are persona-based which facilitates easy identification of missing stakeholders and requirements.
They force stakeholders to describe the justification and value associated with a need.
They can be used in conjunction with many other elicitation and documentation techniques. Remember, user stories are a modelling technique that can be combined with any other technique that is used to draw out information relevant to a change or to communicate said information.
They are generally low-cost to create with respect to time and the consumption of human resources.
Limitations of User Stories
The following is a summary of the key limitations of user stories:
They are intended to enable the rapid specification of requirements and may not be useful for long-term retention and transfer of business context knowledge.
They may not provide sufficient understanding of a business context by themselves. Often, you may need to supplement user stories with one or more additional modelling techniques.
Business analysts should consider the benefits below when determining whether user stories are appropriate technique to use in the context of their specific projects or initiatives.