Identifying Business Concepts with User Stories
A story is always something that the business values. Think of a story as a thin vertical slice through the horizontal layers of the system. Quantifying the business value can be informal. User Stories make the team focus on how the product will behave rather than how it will be built. User stories are independent of each other. This means they can be implemented in any order. User stories should not contain every detail for the implementation. We want those details to be negotiable between the developers and the business. A user story must be concrete enough for developers to estimate it. The story must have clear and quantifiable value to the company. A user story should not be larger than one or two developers can put in place in a single iteration.
Quantifying the business value can be informal. Some teams might use high/medium/low as their business value scale; others might use a ten-point scale. An iteration should contain about the same number of stories as there are developers on the team. The stories that are valuable but cheap will be done right away. Those that are valuable but expensive will be done later. Those that are valuable and inexpensive might get done one day. Those that are not valuable but are expensive will never be done.
The best predictor of the progress of an iteration is the previous iteration. The project is still ongoing when all the stories are implemented. The project is over when no more stories are in the deck worth implementing. The main advantage of User Stories is sharing the model in which a user thinks about the system. Instead of focusing on how to build something, delivery teams consider how their products will be used. Ideas can be debated and analyzed by defining the expected behavior in a shareable form. Refactoring is never a story. Architecture is never a story. Code cleanup is never a story.
In describing any need, many concepts might be necessary for the user. By looking at how the condition refers to actions and names, we can grab most of the abstractions we need at least to start experimenting.
User Stories follow specific characteristics that make them reusable. For instance, When defining a User Stories is preferable to use a declarative style over the imperative one.
The imperative style is too concrete and specific, reducing flexibility and expression. Making user stories declarative suggests an abstract language to describe a problem.
The standard way to write User Stories follows a specific template:
To <Behavior change>
As <Role>
I want to <Expected outcome>
Behavior change: This is the behavior the team wants to influence in a user. User stories describe the higher-level behavior of a user.
Role: Which Role will the user play in the Behavior change context? Defining roles is essential to split and group functionality based on users.
Expected outcome: Describe the result of the behavior change. The functionality that users and developers agreed on.
User stories expose business vocabulary in Identifying the concepts the user story describes the code-base, and alignment solidifies. The following is a definition of a user story for an appointment scheduling software with a list of an initial group of business concepts.
To see patients at a specific time and date
As a Doctor
I want to be able to schedule appointments with my patients.
- To see
- Patients
- Patient
- Specific Time and Date
- Doctor
- Schedule
- Appointment
After identifying the business concepts, we can define questions to discuss with stakeholders.
- Does a doctor have a different way of identifying?
- How many appointments can a doctor have in a day? Is there any time limit?
- What is the preferred format for scheduling an appointment?
- Is there a limit on the number of patients a doctor can see daily?
User Stories are not complete requirements but tokens of conversations. More of a question than an answer. User stories thus represent a contract between stakeholders and the delivery team. Creating a user story promises that the business stakeholders and the delivery team will meet at some point to discuss the details. A basic understanding of the language used at the business level can propel alignment and effective execution for code delivery.
