There is more to the user story 📖
In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index cards, Post-it notes, or digitally in specific management software. Depending on the product, user stories may be written by different stakeholders like client, user, manager, or development team. — Wikipedia
Most people involved in software development know of user stories. Some preach about it, some disdain it and some simply do not understand it (or do not care about it). User stories are highly tied with Scrum and Agile, but they actually originated from the Extreme Programming movement, first coined in the late 90’s by Kent Beck. Their goal was to clearly communicate one or more features of the system, presenting the what and the why, so that those features could then be developed (the how).
But there is more to the user story.
A process for the sake of a process is meaningless. Thus, in this article we will be diving into user stories, sharing our opinionated thoughts about them, as well as alternatives that present to be better in different settings. We will be discussing user stories, job stories and persona stories. However, we will not present a new template or way of writing user stories, or suggest that there is a BEST option. There is not, it depends on the team, the context, and what you are building. Nevertheless, we hope that this article invites you to reflect deeper on the processes that you love or hate, and really think them through, instead of blindly accepting them and even worse, enforcing them onto others.
It always ‘depends’.
The communication style will always depend on the audience and type of message that we wish to convey. This is no different within the context of project or product management. Remember that, “a user story is an informal, natural language description of features of a software system”. This is quite a simplified description of a sentence that must convey clearly an arbitrary amount of intricate and possibly complex scenarios. More often than not, it never ‘conveys clearly’. It’s hard. That is to be expected. Assumptions and wider context must come into play to fill in the gaps. This can either be smooth sailing or catastrophic, slowing down product discovery, project deliveries and even worse in the long run, slowly burning out teams.
Lets break down an example user story:
As a music streaming subscriber, I want a personalized playlist based on my listening history, so that I can discover new music tailored to my preferences
The example above does losely follow the traditional user story template of — As a [persona], I want to do [something], so that I can achieve [some goal]. I reckon that the firsts things that comes to mind to the reader are (in no specific order)
What defines a playlist?
What is a personalized playlist ?
What is listening history ?
Are preferences implicit (listening history) or also explicit ?
…
Without much context, based only on this user story, we could go on almost forever, breaking the user story down to its fundamentals. Trying to fill in the gaps, as much as humanly possible. This should be the job of the entire team tasked with implementing such requests.
Context is King
In Scrum, filling in the gaps could happen in one or more ceremonies like backlog refinement or sprint grooming, where the team agrees both on what needs to be done, and how it should be done. The user story is just the beginning of a (ideally short-termed) conversation that everyone both accountable and responsible for building it needs to understand and agree upon. The how is the job of software engineers and UI/UX to figure it out. More often than not, the what has been already refined with UI/UX, and approved and agreed upon by plenty of people — software engineers are typically the last in the chain, weirdly enough, since they are the ones that require the most context to decide the better how. Thus, are more aware of possible constraints or relevant trade-offs that should be taken into consideration. They should be part of the process as soon as possible, right ? right
The important part of the user story to be understood, agreed upon quickly and with no mistakes is the what. The underlying requirements that are often described further as acceptance criteria. Naturally, someone needs to painfully write almost all of them and facilitate conversations between the team to align on what exactly it is that needs to be done. An unsolicited tip length does not have a linear correlation with clarity. An user story can have an obnoxious amount of acceptance criterias and still not be clear. Thus, user stories do not tell the entire story at all, that’s why we need carefully crafted acceptance criteria.
Jobs and Users
There is more than user stories, there is an alternative that focuses on the job — specifically what an user wants to do and expect, ignoring the specific type of user.
Continuing with the example above, if we rephrase an user story to a job story, we naturally gain information that is relevant to the task at hand. For example:
When using a music streaming service, after regularly engaging with songs and artists, I want the platform to dynamically create a personalized playlist based on my implicit preferences derived from my listening history. This way, I can effortlessly discover new music that resonates with my unique tastes and enhances my overall enjoyment of the platform.
In a job story, the persona itself does not matter, it matters only what job the user wants to do, what they expect of it and why they want to do it. It is a small difference, but small details compounded over time have a big impact.
A user story is quite important from a product perspective, where we care more about the experience that we want certain personas to have. When building and planning the initial set of requirements for a product or subset of features, writing down user stories can be quite useful to visualize what the product should be conceptually. However, as we stated above, when it comes to actual development, it is not enough and it can be confusing.
On the other hand, a job story cares more about the feature itself that the team has to build. The non-negotiable acceptance criteria (in bold) can be easily added within the job story itself and we can then enumerate edge cases or other considerations that are not necessarily core to the feature, but would help its makers. At the very least, by using job stories, we remove the weird and cognitive blockers that typically arise when writing user stories like:
“Multiple users want this, but it’s basically the same thing. How do I hand over these requirements to the engineering team ?“
“There are a lot of similarities between these two user stories but there are slight nuances. Do I keep them split or join them and craft an extensive set of acceptance criterias with more details?”
Keep in mind that either can work. Remember, it always depends.
A small side-note, job stories do not seem to get the respect they deserve. Try to use them to your own benefit.
Let uswrap up this section with another example, using real tasks from the development of Scopebrite, a project and product management platform.
The user story:
As a user, when I log-in, if I don’t have an organization I want to create one, so that I can easily organize my projects and collaborate with others.
In Scopebrite, there are multiple personas, with different needs. But since this is a common story, we use the generic “user”. However, what if we had one type of persona that does not require this flow ? Would we write “As an user that needs an organization..” ? Would we add it to the acceptance criteria ? Would we have forgotten to clarify because it was ‘obvious’ and end up with something wrong ?
The job story:
When I log in, if I don’t have an organization and require one, I want to be guided through a seamless process to create one. This way, I can efficiently organize my projects and foster collaboration with others.
The job story removes the cognitive load of thinking about the persona, as a maker, I would prefer receiving job stories instead of user stories, even if some clarification is still needed — it will always be.
Find the right behavior
More often than not, it’s easier to fill in the gaps when we deeply understand the behavior of the user and how that persona expects a certain feature to behave. As we have discussed, both user stories and job stories while providing a high-level view, might fall short in capturing the nuances of user behavior. This is where a focus on behavior-driven development (BDD) or scenario-based approaches can complement the user or job story approaches.
Consider the following scenario:
“Given a music streaming platform user who has been consistently favoriting songs from a diverse range of genres, when this user logs in, the system should curate a playlist that balances familiarity with new discoveries. This way, the user experiences a personalized journey through their music preferences.”
In this scenario-based approach, we delve deeper into the user’s behavior, preferences, and expectations. By explicitly defining scenarios, we bridge the gap between what’s stated in the user story and what’s anticipated by the user. This not only aids in better understanding but also provides a foundation for creating comprehensive acceptance criteria.
The more traditional template is — Given …, When, .. Then.., which indeed captures the entire scenario quite elegantly — the assumptions, the action and its outcome.
Personally, I have been exploring using either user story or job stories and then a scenario based approach to define their acceptance criterias. I must say, it has been working quite well when it comes to clarity. It just takes time. Gladly, Scopebrite, the product I mentioned earlier, helps me out on that.
Persona Stories
In order to know why a user would do something — why do they care — it is better to know their story. After all, to know a person’s story, is to know them….. to a certain extent.
While user stories are a staple in Agile methodologies, introducing persona stories can offer a more holistic view. A persona story considers not just the specific task a user wants to accomplish, but also the broader context of their role, goals, and challenges. All critical points if we are trying to build products that solve real problems.
Let’s explore this in the context of project management:
“As a project manager overseeing multiple teams, I want a comprehensive dashboard that provides real-time insights into project progress, team workloads, and potential bottlenecks. This way, I can make informed decisions to ensure successful project delivery.”
This persona story goes beyond a singular task and encapsulates the overarching needs of a project manager. It provides a narrative that aligns with the user’s role and responsibilities, allowing for a more comprehensive understanding of their requirements. In certain project management methodologies this would be considered an Epic, a collection of somewhat interconnected user stories.
Perfectly balanced, as all things should be…
In the realm of software development, striking the right balance between user stories, job stories, scenario-based approaches, and persona stories is an ongoing challenge. It’s not about adopting a one-size-fits-all solution but rather about selecting the most fitting approach based on the project’s nature, team dynamics, and the complexity of the requirements. Mixing them up and possibly even adapting them, as long as it works, its consistent and everyone agrees. It is typically best to avoid following dogmatic approaches.
Moreover, the iterative nature of Agile methodologies allows teams to continuously refine and adapt their chosen approach. Regular retrospectives, feedback loops, and collaboration among team members foster an environment where the chosen framework can evolve organically.
Conclusion
Understanding and capturing user expectations and requirements in either user stories, job stories or persona stories is a non-trivial task. Each has its own merits and potential pitfalls, but the key lies in staying adaptable. Embrace the dynamism of the development process, listen to your team’s feedback, and let the user stories evolve as your understanding deepens. It is also critical to remember, that in 99% of the cases, the obvious thing is not obvious at all. Whatever the ‘thing’ is.
The end goal is not just delivering features as fast as possible but creating meaningful and user-centric experiences. If everyone in the team is aligned, if what it is that needs to be built is clear and well understood, if the why behind it is accessible, then everyone can help evolve and make it even better.
In upcoming articles I will explore more nuances and go deeper within the topics of project and product management, but in the meanwhile I would love to know.
How do you align and stay aligned with your team ?
What methodologies do you tipically to use ?
What has been working for you?
What is clearly the wrong way of doing this for you?