28. May 2020
Our way of handling user stories

Posted at 09:54h in Insights-En by Johannes Schaffer

In light of the current situation, we put the tools we use every day to the test and evaluate their suitability for everyday use in the home office. User stories are a central element of Scrum. In the following article we would like to demonstrate what makes a user story a good user story for us at XITASO, and what is especially important in the current situation.

What are user stories and how are they built up?

User Stories are quite literally stories from users. In a user story, the product owner describes the requirements from a user’s point of view: How do users want a software to be or how customers want a deliverable, in order to achieve their business goals.

User Stories consist of a few easy-to-understand sentences. They are short, but specific and detailed from a customer’s point of view. User stories not only convey expectations for future IT systems, but also requirements for deliverables that agile projects realize. User stories come to the fore in the requirements area, without switching to the solutions area. They do not provide technical solutions that force developers into stubborn realization and are therefore different from a specification. ¹ ²

A user story should be simple and easy to understand.

“As a [user], I want [function] to [value].”

That means, a user story answers the questions WHO wants WHAT and WHY:

[Users] – Who?
The [User] placeholder is filled with roles or personas. A persona is a typical representative of a target group. The role of the user can also be defined by the respective context. For example, the same role can apply to different personas and describe the relationship to the product.

[Value] – Why?
The placeholder [value] answers the question about the WHY. Even if the sentence construction leads to omitting this subclause, a user story is not complete without this addition.

[Function] – What?
The [function] placeholder is filled with the expectation, goals and wishes of the [user]. In this way, the function answers the question of WHAT the customer needs and expects. If the product is already available on the market, many desired functions will definitely come directly from the user. In earlier phases of a project, assumptions can be made based on the experience of the customer or resp. the product owner and the team, which [function] the [user] expects.

This means that it is only with the [value] that it is first expressed why the achievement of the [function] is important for the [user] at all and what added value the fulfillment of the user story creates. It is at this point at the latest that the user story offers an honest reflection on how well one has already dealt with the requirements of the customers. It is easy to accommodate requests (e.g. because the customer is crying out for a function). But understanding why it is important for them gives the team the necessary context.

This is how we write User Stories at XITASO

Thanks to their easy comprehensibility and focus on the user, user stories are a popular and widely used technique for describing entries in the product backlog of a Scrum team. At XITASO, we use user stories in all our Scrum teams. However, how these are created, how they are structured and what the execution of the sketched “ideal solution” actually looks like, differs in the daily routine between the individual teams and also within a team on a case-by-case basis.

In contrast to the classic approach, we like to especially focus on the “why” of the requirement in the user story by first explaining the “why” in the structure of the user story. Since the team is expected to develop a solution for the customer’s needs, it is crucial to know the motives or the problem faced by the customer in order to be able to offer alternative solutions, if necessary, which can be more effective or cheaper. Furthermore, in prefixing the “Why” you start by putting yourself in the customer’s shoes at the beginning of the user story and thus seeing things through the eyes of the user.

At XITASO, we not only work on new software products, but also on improving existing products. In this case, the user stories often refer to existing functionalities. For example, a user story for an existing online store might be: “In order to be able to process the payment for my order quickly and conveniently, I, as a customer, would like to link my credit card information to my account.” Now the questions of who wants what and why, have been answered. However, it remains unclear what the current situation is. Could the customer not pay by credit card up to now or is it already possible, but the customer has to re-enter the credit card information every time they place an order? Depending on the initial situation, the expectations and urgency of the changes for the customer may change. In order to achieve a better, common understanding of what is to be achieved with this user story, it has turned out to be useful for us to add a “whereas currently” subclause to such stories, which describes the current, to-be-improved situation: “In order to be able to process the payment of my order quickly and conveniently, I, as a customer, want to link my credit card information to my account, whereas currently I have to re-enter my credit card information with each purchase.”

We have also worked intensively on the question of whether and to what extent acceptance criteria should be (pre-)formulated in the creation of the user story. It is clear that the acceptance criteria are to be defined in the dialogue between the developer and the product owner. But are the acceptance criteria of all impending stories actually formulated during the backlog refinement? Or could it make sense for the product owner to establish certain acceptance criteria when the story is created, which can then be discussed and changed during the backlog refinement? On the one hand, our experience has shown that it can be advantageous to formulate acceptance criteria in advance in order to communicate the desired changes to a larger team. Thus, a framework is given for the discussion and definition of the criteria and time can be saved during the backlog refinement phase. However, this approach is countered by the thesis that acceptance criteria formulated in writing already provide a line of thought and may thus prevent creative solutions. It is therefore important to balance time savings against creative solutions. A possible compromise could be that the product owner has already considered the acceptance criteria in advance but has not yet fixed them to the user story. In this way, they can compare and consult with their notes during the course of the conversation and, if necessary, incorporate their acceptance criteria.

Depending on the role structure they occupy between the client/customer and their team, the product owner is completely left to create the product vision and thus the creative part in the production of the user stories. In the case of a strong visionary on the client or customer’s side, the product owner rather assumes the task of a requirement engineer, who pours the requirements into a mold that fits with agile software development and yet represents the customer’s view and its product vision to their Dev team. In the latter case, the product owner often lacks the decision-making power in practice to answer all questions or even to agree to alternative solutions on the part of their team on an ad hoc basis. It is therefore advisable to create the user stories early on and present them in a team discussion. This leaves enough time before the start of the realization phase to precipitate necessary clarifications with the client or customers.

What are the special requirements presented for the user stories by the remote situation?

At the moment, the Corona crisis is also presenting our daily work routine with new situations and special challenges. From this point of view, we also want to check whether the user story is still suitable or requires adaptation, for a team that now works with each other, completely remotely. To this end, we take a step back and ask ourselves again what purpose the user story should serve. The user story is intended to convey the requirements for a system to the development team from the perspective of the user, in a few sentences. Of course, the user story also meets this requirement in the remote situation. The product owner uses the user story at the beginning of the planning and at the beginning of the refinement in order to explain the problem to the team. In addition, the user stories are consulted in the ongoing development process, in order to recall the connections between individual tasks or resp. to check again whether the requirement has been fulfilled in all details in the sense of the user when completing the realization. Especially here it is advantageous if the user story has been described in some detail, because in the remote situation not even the neighbor or the product owner sitting nearby can be asked to check one has understood everything correctly.

The correct and complete understanding of the user story is of course also necessary in the regular planning and refinements. In addition to the additional attention to higher detailing, further tips can help to achieve optimal results in these meetings, even in the remote situation. Thus, the product owner should pay even more attention to the facial expressions of their listeners. A frown, or even looking away, can often be indications that the listener is already lost, or still thinking it through. With targeted enquiries, the product owner can check whether there are open questions of understanding and record the answers, in writing, in the user story.

From the experiences we have gained in remote teams and especially those from the last few weeks, we have derived many more hints and tips that we have collected in our video podcast, blog articles and the webinar series Agile Wednesday. We would be delighted, if we have aroused your interest, that you have another look at some of these in the future.

Some tips for good user stories

Card, Conversation and Confirmation

Ron Jeffries mentions three critical aspects that should be considered when creating user stories: Card, Conversation, and Confirmation.

Card
Stories are traditionally written on cards. Therefore, product owners should be brief and not use up more space than the card allows.

Conversation
Requests should not be thrown “over the fence” by the development team. Product owners and developers should talk to each other about the cards in order to sharpen the understanding of all stakeholders. Because the devil is in the detail, as they say. Only in the conversation does it become clear whether the developers really know what they should build. Developers and product owners should define the acceptance criteria together in a dialogue. When a user story is formulated, developers will typically confront the product owner with the questions whose answers lead to the acceptance criteria.

Confirmation
A user story is completed when the acceptance criteria are met. They describe what is expected of the story in order to be reported as “finished.” Acceptance criteria are flexible and adjusted, if necessary, until the team starts realizing the user story. The Scrum master and the development team will discuss whether there is a common understanding. In this way, misunderstandings are avoided, which would otherwise have to be eliminated in a time-consuming manner. ¹

INVEST principle

In the best case, every finished user story should be written according to the INVEST principle:

I (Independent): It is not dependent on another user story.
N (Negotiable): It serves as a basis for discussion and can be further developed together.
V (Valuable): It always represents a benefit for the user, customers or client.
E (Estimatable): It has so much concrete detail that an experienced team can estimate its scope.
S (Small): It is the right size.
T (Testable): It contains enough information to be tested. ⁴

More tips

In addition to the INVEST mnemonic, there are other tips for creating a good user story:

The user should always be in the focus.
User stories are not created by one person alone; teamwork is required, and communication is particularly important.
Acceptance criteria make the work easier.
Less is sometimes more; user stories should be formulated in a short and precise manner.
Stories should be visible so that everyone can see them and have a presence.
User stories are not a universal remedy; it doesn’t always make sense to write a user story, don’t feel obliged to do so. ⁴

Dealing with user stories which are too big

If user stories are too comprehensive, the team can hardly reliably estimate the effort. Therefore, the product owner splits the requirements into smaller units. What is the best way to do this without losing valuable information?

Formulating the User Story Vertically
This means addressing different areas of a technical system, such as front-end and backend, for example. At the end of a sprint, the customer should have a completely usable functionality.

Focus on the greatest benefit
Does the requirement have a simple core? Does this promise the greatest benefit to business? Organize by business case and focus on those with the greatest benefits.

Reduce complexity
Options and complexity should be reduced. For example, if the user does not need a complex interface, it may be possible to start with a plain and simple design.

Splitting a user story
Large user stories should be split by functions, actions, or operations that the user can perform separately. ¹