What is a user story?
A User Story is a sentence on a card that tells a user's experience with a product. User Stories make the necessary communication between users and developers visible to develop a product.
What are User Stories used for?
User Stories always refer to the product and the user experience. Because of their briefness and focus on the customer they are especially suitable for Scrum and agile work.
User Stories are often mentioned with Scrum. Although Scrum does not dictate how a Product Backlog item is described. A User Story is one possible technique to describe a Product Backlog item. It facilitates communication between the team and the customer.
Why use User Stories?
User Stories were originally developed in the eXtreme Programming (XP) community, like many development practices that are taken for granted in modern software development today. Like a Scrum Team, an XP Team focuses on delivering a finished product increment. The team achieves the highest form of "done" when the new product increment increases the value for the user. The team must therefore design the necessary functions with focus on the user's interaction with the product.
How the whole thing is implemented and realized is not the focus of a user story. And in fact, the user is very little interested in whether a database, a microservice or a GUI component is needed for the implementation. He measures success by what the product does for him. This makes User Stories perfectly suited for the Product Backlog in Scrum because it serves to optimize the value of the product during development. In Scrum the Product Backlog is the list of things that the product improves.
How do I write a User Story?
With this understanding it is straightforward to write a User Story. You just have to remember: A User Story is written on a card as a well formulated sentence that others would like to read easily. Here, for example, is the user story for an online Scrum training.
As a team member I understand how to decompose a User Story so that I can regularly refine the Product Backlog with the stakeholders.
This sentence contains the three essential information on a User Story card: the value, the user and the function. Of course, the sentence alone does not make a really complete user story. Rather, the overall experience for the user is created by a multitude of such cards, which can be found in the product backlog of Scrum. But we stay agile because we can change the user journey at any time by re-sorting, objecting or adding new cards. This allows us to optimize the value for the user even during product development.
There is another good reason why we like writing user stories on cards. If it is too long and therefore does not fit on a card, then simply write a new card. This way we remain flexible and the user story is not too big and becomes difficult to implement.
What is an epic?
Nevertheless, you often find user stories in the product backlog which are too big to be realized in a sprint. The User Story is then marked as an epic. This means that the Scrum team has to work with stakeholders in time to make them smaller.
Why do you have to make user stories smaller?
Making them smaller or bringing them to the right size is means for the team to clarifying the content of the user story and to reduce its complexity. User stories help tremendously in this process to keep the focus on what value we add to the product. However, teams often cut their user stories in the wrong way - and the actual goal of delivering value to the user is lost.
How big should a user story be?
One of the most important skills a development team needs to master is to collaborate with stakeholders to get their backlog entries to the right size. User Stories are perfect for this because they focus on real added value for the user. Practice has shown that a good size is reached when a user story can be completed by the team within a week. Important: This refers to the time from starting the work until the team reaches the "done" state according to the Definition of Done, not the working time that is invested. Depending on the general conditions, this can vary considerably.
Techniques to deconstruct user stories
The first and probably the simplest way to make a Story Card smaller are conjunctions. You often don't even need to read through the card, just look for bullet points, connective words or bullet points. For example:
As an online student, I can use a quiz to reflect on what I've learned, so that what I've seen in the video is better memorized and the result is sent to my team members as an incentive.
These are potentially two user stories:
Send the results to my team members as an incentive.
Reflect with a quiz to memorise what I have seen.
Well, it couldn't be simpler.
#2 acceptance test
The second and probably most powerful technique is acceptance testing. Asks yourself the question, what would the user do to check that the new function is acceptable for him. For example, the following acceptance tests are available for the Quiz User Story:
- The quiz is starting after the video.
- After a question I get feedback on what I did right or wrong.
- The progress is displayed.
- There is an evaluation of the results at the end.
Each of these testcases is a potential new user story. The only thing missing is the user and why he wants to do it. The testcase "There is an evaluation of the results at the end." becomes:
As a student I receive an evaluation of my quiz so that I can see what I have not yet understood.
Here you can see the potential of user stories. Parts of it I might only realize in later sprints or not at all. A simple quiz feedback after each question might be sufficient for the beginning and the user has a first real benefit.
A user story can also be broken down by looking at the objects. For example, the quiz can consist of different types of questions, such as yes/no questions, multiple choice questions, puzzles, and so on. Each object is a candidate for its own user story.
Or you can cut based on the actions. For example, the trainer can recreate, move, delete and duplicate a quiz. Even if "create and delete" does not yet offer much comfort to work with, it is sufficient.
#5 Temporal order
But often it is also easier to simply decompose the user story in chronological order or the sequence of activities of a longer process. For example, create an account, select a payment method, confirm the purchase, send a link to access.
We can now formulate the part "payment method" as an independent user story. Unfortunately, the user does not get much out of it because he or she can still not start learning. Apart from the question of why we torture the user to go through such a far too complicated sales process. Nevertheless, it might be useful for the team to start here because connecting the payment method involves the highest risk for the implementation.
Most of the time, and especially in software development, these five steps are sufficient to decompose user stories. If not, then there is still the possibility to take out aspects. More about this in the section on non-functional requirements.
What are non-functional requirements?
Let's assume your local car salesman makes you two offers. A standard VW Polo and a Porsche 911. All of them have the same functional feature: "As a working person I can drive from home to work " and "As a family man I can take my two children to school " Well, for the Porsche, at least one child is not sitting comfortably in the emergency seat in the rear. And faster than with the Polo, you won't be at work in rush-hour traffic with the Porsche either. Nevertheless, there is a big difference between the two, such as compactness, sporty design or comfort. We are talking about non-functional requirements of a product. For online training, these may be properties such as availability, security of user data or multilingualism.
How do you recognize non-functional requirements?
Non-functional requirements are often referred to as aspects or constraints because that this describes at best how you recognize them. They restrict or are a base requirement of each individual functional requirement in the product backlog. User stories are most probably functional because they draft an interaction of the user with the product. However, every single user story in the product backlog must be available in five languages and can be used by 1000 users simultaneously.
Why are non-functional requirements so important?
It quickly becomes clear that such a requirement has a much more fundamental impact on the product than a simple user story. A source is therefore often also the product vision. The Product Owner needs to incorporate the non-functional properties into his considerations about value, cost and risk of product development from the very beginning. They thus strongly determine the order of the user story in the product backlog. For the development team, the non-functional requirements are the basis for its decision on how to build the architecture and design.
Definition of Done and User Stories
Together, the product owner and development team must consider how to continuously comply with these aspects and constraints. Therefore, they include them as test criteria in the Definition of Done. On the other way, each entry in the Definition of Done should be traceable to a non-functional requirement.
Removing aspects: The 6th technique to decompose user stories
Aspects are also the access to the sixth technique to make user stories smaller, or rather to reduce their complexity for implementation. An aspect can easily be deferred in the product backlog by the product owner. However, this means an increased risk and high costs at a later stage.
For example, a barrier-free user interface can easily be created later if the team has considered it in the software design. However, aspects such as scalability and security can only be retrofitted at great expense. The fact that the product is installed on a test system, or that it is first used as a prototype in the laboratory, are also aspects that can be consciously used to increase the quality of the product from sprint to sprint and thus the scope of the definition of done.
It is not for nothing that we speak of a potentially deliverable product increment. In order for it to be deliverable, the product very often needs non-functional as well as functional improvements. The team weaves new aspects into the product design with every sprint, so to speak. Some teams also have to go backwards in this process. They do not talk about aspects or constraints that they want to implement, but about technical debts that they have to reduce.
When should user stories not be used?
For non-functional requirements it often makes no sense to use user stories. Especially for hardware-centric products, real user stories are rather rare. Simply because there is no or only little user interaction. For example: A production machine can be switched on and off. Anything else does the machine by itself. Or the autofocus of a camera, which is highly complex in itself. A team need to run several sprints until it is good enough for delivery. On the other hand, hardware is supposed to form a stable basis for constantly offering users new functions or improving existing ones via software. Here, design goals and test cases can be used as items for the product backlog.
Software Tools, User Stories and Scrum
Unfortunately, some software tools such as JIRA, confuse by referring to a backlog entry with the term "story". As a result, the actual purpose of this very lightweight and elegant technique is often lost.
Stakeholders and teams often blindly follow the tool's instructions. They try to specify everything with user stories. A backlog item, however, should only be understood as a reminder for a conversation. This conversation must be continuing until the product backlog item is finished, not until it is perfectly formulated. In many cases, user stories help the team to focus this conversation on what is important.
It takes more than user stories to maximize the value of a product.