What is a User Story?
A User Story is a short description of a small piece of desired functionality within your product that is written from a user’s perspective. They are the modern form of requirements that are used by most Agile teams today.
Agile requires User Stories because it describes scenarios and needs from the user’s perspective rather than describing the solution. This is both a simplification and rooted in philosophy. Whereas traditionally there may have been Business Requirements, User Requirements, Functional, and Non-functional requirements — all of this is distilled down in modern Agile development, to the idea of a User Story, which distills everything into this compact and contextualized story-based format.
This method allows for the team to design the solution in response to the needs identified by Product, rather than Product explicitly defining everything to the team. And the format of the user’s perspective provides the context to look at the need from the perspective of the user, rather than jumping directly into form and function.
How Are User Stories Managed
User Stories are written at the start of development and are traditionally written on notecards or sticky notes, to keep the process lightweight. They would be organized on tables or walls to encourage communication with the team. This process builds empathy and understanding of the end-user right from the start of development. Today, most teams work on digital equivalents to these cards and boards with tools like Jira and PivotalTracker.
Once the User Stories are written by the team, a backlog is created that fully describes the functionality that the team will be developing. New user’s stories are often added throughout the development lifecycle as discoveries occur.
Who Creates a user Story
User Stories are typically written by the Product Owner for the team. There are no hard and fast rules as to who writes the User Stories, but that is generally the case since it is the Product Owner who is determining the “what & why” for the team – User Stories are the unit of requirement for achieving that outcome.
When a User Story is created, they should ideally be empathetic to the end-user and also invested in the development of the product themselves which is why it’s encouraged for the whole team to take part in the process.
Types of User Stories
There are multiple types of User Stories that a team can create, and they often vary depending on what the team is developing.
Epic Stories – Epic Stories are large in scale and detail about the imagined user or are multiple small stories that are similar. Epics are often referred to as User Stories that are far too large for a sprint.
Splitting Stories – Often larger stories are split into smaller stories so that they can get through a sprint fast, reducing risk.
Enabler Stories – If the end-user of the product is more of a place or a thing rather than a person an enabler story is created. These are often used for architecture and infrastructure projects.
User Story Format
A successful User Story is simple, straightforward and follows this format:
As a [who] I need [what]so that [why]
For example:
As a teacher
I need a portal to store my students’ homework
So that it’s organized and all online in one place
By creating this simple user story, the whole team now understands who the end-user is and that the final goal is a well-organized portal for the students’ homework assignments.
User Story Three C’s
The three c’s refer to the three core elements of a user story.
Card – User stories were historically developed on notecards or stickies to keep things nimble and moving. On the front of the card you’d should have a unique “story identifier”, the user’s name and title, and an “As a, I need, so that….” statement. The back of the card should have the acceptance criteria.
Conversation – creating a User Story is a team collaboration and encourages conversation, everyone’s input is important. All steps of the story lifecycle should be covered in the conversation which includes:
- Backlog Refinement
- Planning
- Implementation
- Demo
Confirmation – A User Story is not complete until the acceptance criteria have been met. Acceptance criteria examples:
- Can my students upload their homework directly to the portal?
- Will my students be able to see live feedback as I grade their homework?
- Will I be able to access this portal anytime and from any place?
Investing in Stories
Bill Wake created the acronym INVEST to help determine if a story is a good User Story.
- Independent – Standalone from other User Stories
- Negotiable – A statement of intent that is flexible (not a contract)
- Valuable – Clearly outlined value-added features for the end-users
- Estimable – Able to create time estimates for completion
- Small – Should be small enough that they can be completed quickly
- Testable – Able to test results for confirmation of success
Estimating Stories
Once the User Story is complete the team will now estimate the duration for the user story to be complete. The estimation uses “story points” to represent an abstract but relative indication of size (aka “level of effort”). It has become tradition to use Fibonacci sequence numbers (1,,5,8,13, etc), in order to have a sequence of numbers that progress in meaningfully larger units, so as to not get stuck debating 11 versus 12 points, for example. These story points provide an approximate level of effort estimate to the Product Owner, who can compare that to perceived value and prioritize the backlog considering both benefit and cost.
The following should be considered in the story point estimate provided:
- Volume – How much work does the team need to complete?
- Complexity – What is the level of difficulty?
- Knowledge – What are the certainties?
- Uncertainty – What are the unknowns that may be encountered?
Conclusion
User Stories are an essential tool in the development of a new product. They encourage team collaboration and communication, as well as team, buy-in before development begins. User Stories also create empathy for the end-user which ultimately results in a better product.
