We’ve got the famous format of user stories: “As a, I want so that”. I’m not too concerned about the actual format. Important is that a user story describes something that solves a problem in the user’s domain from a user’s view. In this post we’re discussing why user stories from a user’s perspective are important. Generally, I see the following advantages compared to “stories” that are written more like traditional requirements, e.g. “Interface X delivers value Y in format Z”:
- 📬 Done means something is realised that probably helps the user
- 📌 Definition of details can be postponed
- 📁 Clear structure helps to prioritise
- 📝 Stories are understood by users and stakeholders
- 👩 It is clear that a user is the target audience
Next, let’s deep dive into those advantages and discuss them in detail.
Done means something is realised that probably helps the user
What happens if you have user stories like “Interface X delivers value Y in format Z”? You are not sure if something valuable to the user is delivered when the story is done. On the other hand something like “As a registered user I can go through a ‘password forgotten’ process, to ensure I can always log in” has a clear statement and benefit. As soon as this story is done the user is able to recover when forgetting his password. That makes the user happy and most likely decreases the amount of emails in the support department.
As soon as the story is done value is realised. Given that the story is released to at least a subset of users and actually satisfies those user’s need.
Additionally, if the story is independent from other stories, you are sure you can deliver the story independently and still create something meaningful for the user. So, no need to discuss a lot about dependencies between stories.
You can also read our post about the frequent delivery of value to understand the importance of this point.
Definition of details can be postponed
When you define a user story from a user’s view, you can omit all the technical and design details. Like that you can postpone those decisions to the last possible point in time. This ensures that you are basing the technical and visual design decisions on the latest information. Furthermore it also means you did not waste time with unnecessary work if a user story is put into the bin.
Clear structure helps to prioritise
When user story descriptions follow a certain pattern it is more likely that they end up having the same abstraction level. Things with the same level of detail are easier to sort and prioritise. Let’s have a look at the following example. You can decide for yourselves which variant is harder to prioritise:
- Add a “Password forgotten” link to the login form
- Create a button for the order’s overview on the confirmation page
- As a registered user I can go through a “password forgotten” process, to ensure I can always log in
- As a customer I want a direct link to my orders when I land on the confirmation page to have a status overview of all my orders
In both cases we just add a link (and a whole “password forgotten” process for the first one). In the second variant it becomes clearer what the user (and the company) gains from each story.
Stories are understood by users and stakeholders
Having a story written from a user’s point of view makes it clearer to understand for all people involved. Users or customers don’t need to ask what changes if interface X delivers value Y. Instead they know what they are getting. The discussions around a story between developers (and/or PO) and the user can focus on the problem to be solved without having too much technical details that only distract.
It is clear that a user is the target audience
The user is explicitly mentioned. Hence, the solution should always be designed having the user in mind. Compare this to too technical stories where the user doesn’t find its place. There the user’s need is neglected and we might implement the “story” without really solving the user’s problem. This only causes rework in the end or unhappy users. A software is not something that is created just to offer some features. A software is a product that helps its users to do some tasks or solve problems. Finally, the target audience focus means that we know from where to get feedback about the implementation. Then we can iterate and improve.
Conclusion – User Stories from a User’s Perspective
As always with Agile development, practices should probably differ from team to team. Every team is different and chooses its own best way of working (see also this article). Of course teams can always break down work into smaller chunks or tasks that are then more technically formulated. But having the user story as a base gives the developers the right focus to deliver something of value to the users.
Please also be aware of the following points when using the “As a … I … such that …” pattern:
- Not everything needs to be a user story. Alternative approaches like job stories could be more fitting in some cases.
- When expressing a certain user story in the pattern doesn’t feel right, then stop. Try it in another way. But just have in mind that the goal is to deliver value.
That is why I emphasised the user’s perspective in the introduction rather than the exact format.