“User Story” is a term frequently encountered in Agile development, describing a new feature to be implemented from a user’s perspective. However, as is often the case in Agile, this term is sometimes misunderstood or misused. So, what exactly lies behind these famous User Stories?
Who? What? Why?
A User Story represents an action (or series of actions) performed by a user to achieve a desired result. When we hear this, the Product Owner (PO) in us might ask:
- Which user? Is it a customer? An admin? A free trial user?
- What actions are they taking? Which feature are they using?
- What result are they trying to achieve? What need is being addressed?
To answer these questions, a widely known template is often used as a guide for writing User Stories:
As a
I want to
So that
For example, for an informational website, a User Story might be:
As a paying user
I want to save posts of interest
So that I can easily find them in the future
While this template isn’t mandatory, a good User Story should still contain this information to clarify who the user is, the action they want to take, and the goal behind it. Focusing on the “why” helps ensure the feature adds real value to the product. It’s better to have fewer, high-value features than to accumulate unnecessary functionalities that poorly address user needs.
Additionally, these brief sentences are often used as headers in “.feature” files for Cucumber, giving context to implemented tests. When you review these tests weeks later, you might have forgotten the details of prior discussions, and these statements will help you quickly recall the topic.
So, is that all there is to a User Story?
Not quite! A good User Story also meets several other criteria, more focused on implementation needs. These requirements are encapsulated in the acronym INVEST:
- Independent: It should be as independent as possible from other User Stories to simplify task management within a sprint.
- Negotiable: Its scope should be flexible. What the PO proposes isn’t set in stone. Developers should have leeway in implementation choices.
- Valuable: Here, we return to the “why” mentioned earlier. A User Story must address a real need.
- Estimable: The technical team must be able to commit to a specific duration for the task.
- Small: A User Story should be as small as possible. The smaller the story, the more confidence the team has in the estimated timeline.
- Testable: Often overlooked, testability should be considered during the design phase. If a feature can’t be tested, how can we trust it?
A User Story can also be complemented by several elements to ensure it’s fully understood by everyone involved. This might include design files (Marvel, Figma, etc.), business rules, flowcharts, edge cases, and more.
Okay, that’s clear, but doesn’t that make a User Story quite big?
This is where confusion arises. There’s often misuse of the term, and while a User Story should be small to meet the INVEST criteria, we often hear that stories need to be broken down into smaller ones. This leads to uncertainty about which User Stories require the “As a… I want… So that…” format.
To avoid this ambiguity, I prefer using different terms for different concepts. A macro-feature is called an Epic. By macro-feature, I mean any concept large enough to have multiple options/screens/features. For example, the purchasing system on an e-commerce site or the onboarding process for an app. Each Epic is made up of several User Stories, and each User Story can be further divided into tasks. This results in a three-tier breakdown: Epic → User Story → Task. While this structure might not cover extremely complex systems, it handles the vast majority of cases effectively.
When working with User Stories (US), there are different ways to break them down into smaller tasks. These approaches depend on various factors, from functional requirements to technical needs or even focusing on testability. Here’s a look at some common strategies:
• Functional Breakdown: Each task focuses on adding a specific functional rule. For example, one task might involve adding a specific validation or feature.
• Technical Breakdown: Here, each task corresponds to a different layer or technical requirement in the software. This could mean separate tasks for the frontend, backend, or database layers.
• Testability-Centered Technical Breakdown: In this approach, the focus is on building and testing incrementally. For instance, you develop the frontend first, test it, then connect the API and test both together, and finally, hook up the backend and test the entire system. Using mocks at various levels can also help in future maintenance.
Each strategy has its pros and cons. However, in an Agile setting, functional breakdown is often the most effective because it ensures that each User Story adds clear value to the product. This method aligns more closely with delivering incremental improvements and prioritizes the user’s perspective.
One great way to perform functional breakdowns is through workshops like Example Mapping (more on this in an upcoming article!), but many other methods can work too.
Measuring User Story Success
A good User Story should also include a way to measure how it’s being used by customers. This helps determine whether the feature resonates with users and whether to continue investing in that direction. Plan for this measurement during the User Story’s conception. Create tasks for developers to implement tracking flags on key buttons or interactions. Finally, set reminders to analyze the collected data after a few days or weeks of usage.
Isn’t This the PO’s Job?
Absolutely, but as the quality gatekeeper, it’s also your role to remind and promote these best practices. Often, these rules aren’t fully followed, which can harm the quality of your work. For example, you might find yourself unable to test a User Story properly, or you might not know which users should have access to a feature. Don’t hesitate to challenge the process or your Product Owner (PO) if necessary. In the end, everyone benefits from following solid practices.