By Alexandra Maratkanova (asmaratkanova@edu.hse.ru)
Let us begin with defining what the requirements are. Software requirement is a property that must be exhibited by something in order to solve some problem in the real world [1]. Software requirements can be of two types: functional requirements and nonfunctional requirements.
Functional requirements describe the functions that the software is to execute [1]. They describe how the system shall process information or respond to user requests. Nonfunctional requirements are sometimes known as constraints or quality requirements [1]. They are the ones that act to constrain the solution. Nonfunctional requirements usually come from outside the project, like lows, trends, customer constraints, etc.
Nonfunctional requirements usually are either explicitly stated or come from experience or knowledge of the project scope. Functional requirements are much more challenging to define. To make this process easier, a variety of techniques are used. User stories and job stories are one of them. This essay is dedicated to their advantages and disadvantages.
The SWEBOK describes user stories as “This technique is commonly used in adaptive methods and refers to short, highlevel descriptions of required functionality expressed in customer terms”[1]. User stories provide the team with information to help them estimate the efforts required to implement some functionality. User stories are part of Agile Methodology due to the ability to change requirements quickly. They follow a specific pattern: “As a < role >, I want < goal > so that < benefit >.” The Agile User Story Mapping [2] gives an example of such a user story:
“As a shopper I want to search for cheap items so that I can save money on my shopping.”
A User Story Mapping is used to define requirements using user stories. It consists of three steps:
The first one is to find personas. We begin with stakeholders. Stakeholders are all people who are interested in the project. It could be users, customers, etc. Then, stakeholders are divided into groups. Those groups are represented through personas. Personas is a description of a fictitious person based on data collected about the target user group [3]. Each persona has its own goals.
The second one is to split personas' goals into steps. Steps represent actions that the user must complete to achieve their goal. Steps often represent epics during development.
The last one is where user stories appear. User stories represent the granular level of the map. Each of the user stories' goals leads to fulfilling the step the user story belongs to. That leads to fulfilling the personas' goal.
Job Stories is a part of the JTBD framework. Jobs-to-be-done (JTBD) is a framework for understanding customers and their motivations for adopting a new product or service [4]. All job stories follow the pattern: “When <situation> I want to <motivation> so I can <expected outcome>.” An example of a job story would be:
“When an order is submitted, I want to see a warning message so I can avoid resubmitting the order.”
To create a job story, follow these steps [5]:
The first one is to create a high-level job. A high-level job is some action for which a customer “hires” a product or service [4]. The goal of the product or service is to provide the best solution for the action that the customer has to perform.
The second one is to identify smaller jobs that help resolve the high-level job. Smaller jobs are the steps of some high-level jobs. For example, to fill out the loan application, the salesperson and customer enter information about the car and the loan's conditions. Because the data is sensitive, the customer feels their personal information needs to be safe with the car salesperson. Filling information about the car and the loan's conditions and safety of information would be smaller jobs.
The third one is to observe how people solve the problem now. This spet is essential for identifying the job they currently use. This stage is crucial to ensuring the value of the product. At this stage, the team must analyze the existing solutions and ascertain that the product or service solution can outperform them.
The last one is to come up with a Job Story to investigate the causality, anxieties, and the customers' motivations. Providing more situational context, such as the when and where of filling out the form and understanding each party's anxieties can help flesh out the details.
User Stories have many advantages over other techniques when used with Agile methodology.
First, user stories require constant collaboration between the development team and stakeholders. Unlike requirements or use cases, user stories aren't meant to stand on their own. Instead, each user story is a placeholder for a future conversation with the development team that allows a better understanding of what stakeholders expect to see in the product.
Second, user stories use personas. Personas allow a better understanding of each stakeholder group. By prioritizing and addressing personas' goals and motivations development team ensures that their product meets all stakeholders' expectations.
Third, user stories are more precise because they emphasize verbal communication. Written language is often imprecise, and there is no guarantee that a customer or developer will interpret a statement the same way. Verbal communication helps to eliminate misunderstandings.
Fourth, user stories offer an overall understanding of the product. While lists of requirements created by business analysts are helpful, they do not provide a complete view of a product. On the other hand, user stories offer a more descriptive and insightful perspective on the product, allowing for a better understanding of the user's needs and how they relate to the product.
Yet, both personas and user stories can fail. Personas are often defined by attributes that have nothing to do with causality, for example, someone’s age, sex, race, and weekend habits. Personas fail when such information gives no definitive answer to the customer's goals for using the system. User stories can fail for three reasons: when their personas fail when they mix implementation with motivation and outcomes, or when they are unable to capture context, situations, and anxieties.
When user stories fail, job stories can help. Job stories leave behind all unnecessary assumptions. They discard personas and their motivations and focus only on what the user needs to do in the system. It shares most of the user stories' advantages but misses a deep understanding of the stakeholders' needs.
From the definition of user stories and job stories, we can see that, when defining the requirements, they do it from absolutely different angles. I believe that user stories are heavily focused on user expectations. Projects that are based on outsourcing can benefit from such an approach. In this scenario, the primary stakeholder would be the company that commissioned the project, and their viewpoint would constitute the principal source of requirements. Enterprise projects often involve complex systems and stakeholders, making it crucial to have a clear understanding of end-user motivations. Job stories, which provide a detailed account of a user's motivation, circumstance, and expected outcome, can benefit such projects. By focusing on the end-user and their needs, job stories can ensure that the project meets the requirements and results in a high level of user satisfaction.
The user stories and job stories have different purposes. User stories help understand what the users expect to see in the product or service. Job stories help understand why users are interested in the product or service. The choice between them is based on team goals and preferences. Ultimately, both techniques can be used for defining and refining requirements, depending on the specific needs of the project and the team.