User Story

A user story is an explanation of a feature or experience written from the perspective of the intended audience of the feature or experience: the user. User stories are typically a unit of work or a task within the agile framework, and they help the development team understand the value of what they are developing from a non-technical perspective.

User stories are an essential component of the agile framework because they give a people-first or human-focused approach to developers' everyday work. User stories make it easier for developers to collaborate and discuss the work with team members and identify a clearer path to creating something valuable for the user. And with the user kept front and center, the overall quality of the product increases.

In the agile framework, project teams will organize work into specific structures based on their scope and size. Common names for these structures include initiatives, epics, user stories, and substories. 

• Initiatives: a collection of epics with a shared goal
• Epics: a larger group of work including a series of user stories
• User stories: a small request of a feature or experience written from a user perspective‍
• Substories: a more granular user story used to provide additional detail on a specific user experience

The most common structure for a user story is a sentence with modifiable variables that relate to a specific user story. Here is the structure of a user story:

"As a [user/customer/persona], I [want to], [so that]."

• Audience or "user/customer/persona": This part of the user story explains the persona or customer type you will be building your product for. Market segments and personas are ideal for providing a well-rounded explanation of the type of person this story is designed for. If you don't have either, we'd recommend taking a customer that your team knows who represents the audience you intend to develop for. This allows the development team to get into the mindset of the user and be more empathetic toward their needs.
• ‍Intent or "want to": In this section of the user story, you're describing what the user wants to accomplish. This isn't about the feature(s) or interface they're using; it's just about their goals. It should be free of your current solution, jargon, and features.
• Benefit or "so that": This states what the customer is aiming to solve or the benefit they are trying to get at. This is the why behind what your user needs from a solution.

User stories should remain small enough for your scrum teams to put on a sticky note but still have enough detail for them to build out the feature or experience. 

Here are a few examples: 

• As Barbara, I want a way to turn off my air conditioning while I'm away from home, so that I can better control my power consumption.
• As a new user, I want to get an explanation of what the main features are, so that I can get started faster.
• As a customer, I want to reset my password, so I can change my password if I've forgotten it or worry that it has been compromised.

User story acceptance criteria define the requirements a user story needs to meet to be considered complete — that is, acceptable to a user, customer, or stakeholder. Sometimes called the "definition of done," these criteria should include enough detail to be useful to teams without being redundant to other details of the user story or design documents.‍

• ‍Functional Requirements: These criteria describe what the system does and specify the lowest level of user tasks or functions necessary to be considered acceptable by the user. For example, "As a customer, I want my phone to store my photos, so that I can access them at any time."‍
• Non-functional Requirements (NFRs): These criteria describe how a system works and specify what the implementation must meet design-wise or from the user experience perspective. For example, a customer may also want their photos stored securely or to access them quickly and easily.‍
• Performance Criteria: The criteria that specifies a given performance measurement that must be met to deem the user story acceptable. For example, daily data might need to be available for reporting within a certain timeframe.
  

Not all user stories are created the same way or used for the same purposes. You may leverage different types of user stories depending on what you plan on building.

Here are a few types of user stories you may encounter:

• Behavior-driven: Focusing on user actions or decisions
• Rules-driven: Focusing on business rules
• Content-driven: Focusing on display or creation of content. These are a mix of behavior-driven and rules-driven stories.
• Improvement: Focusing on a small improvement to an existing story that has already been completed.
• Integration: Focusing on user scenarios that require technical integration work.
  

• User Story Title: A brief title to use to track and quickly understand the underlying user story
• User Story: The user, their intent, and the benefit or value to be gained
• Acceptance Criteria: The functional, non-functional, or performance requirements that your use case needs to meet in order to be considered done
• Type: The type of user story or the focus of the user story
• Epic: The epic associated with the user story
• Priority: This template is using the MoSCow method of prioritization to rank each story against the others.‍
• Estimate: A time estimate of how long the story could take to complete

Besides building your storytelling skills, user stories are the units of work used within the agile framework to apply context to the tasks within development. Creating user stories is a way to help the development really understand what the user needs.

Using user stories provides the following benefits to development teams:

• The work is digestible. Breaking the development work into smaller tasks helps the development team with understanding the work that needs to be done.
• It keeps work moving. With these smaller tasks, development teams can turn out more completed work which can keep the momentum flowing.
• It brings your customers to the center. By using the persona, segment, or customer as a guide, the development team can get into the right mindset for providing a solution.
• It empowers creative solutions. The way user stories are written, they don't include interface elements or features being used. This lets teams come up with their own creative solutions when delivering on a user story. Obviously, it still needs to jive with the product owner or product manager, but there is flexibility included in user stories.
• It focuses on giving value to the customer. User stories express the value or reasoning behind why a customer wants a feature. This helps the development team understand "why" they are building it.
• It makes it easy to collaborate with others. The user story provides a common set of goals and language the team can use to discuss the user story or work.‍
• It clearly defines expectations. Acceptance criteria define both exactly what needs to be done and when that work is complete

Typically, project teams host a user story writing session at the beginning of the project, but they are often written throughout the entire project life cycle. While the product owner is responsible for the product backlog and writing user stories, it is recommended for all members of the project team to participate in the creation of the stories, prioritization, and estimation.

Typically, user stories are storied and prioritized in the product backlog to be pulled into sprints and completed. Depending on the situation, product teams will include important user stories in their other documentation, like their Product Requirement Document (PRD) or Marketing Requirement Document (MRD), to help communicate with stakeholders.

1. Determine your users: To save yourself time and some headaches, start off by defining who your users will be. This section of the user story will likely be re-used or you may only have a couple of types of users.
2. Set your "definition of done": Write your user stories with an end state in mind. Your user story should be able to clearly define what needs to be done in order to achieve the user's goal.
3. Document subtasks: It's common for your user stories to require additional tasks that need to be assigned to your project team. Keep these tasks in mind as you write your user story rather than putting everything in one.
4. Test user stories with real users: Put your user story and acceptance criteria to the test with real-world users. User story testing ensures they're actually delivering the value they're meant to and that they're acceptable to the personas or users they were made for.

While they seem very similar, use cases and user stories serve very different purposes. A user story is a short, informal description of an end goal, written from the user's perspective. By contrast, a use case covers the user's goals, steps to achieve those goals, and the necessary functional requirements to consider that use case complete.

In other words, use cases include much more detail than user stories. Additional details include: paths the user may take to complete a task; the state or conditions the product must be in before the use case can begin; the happy path or common success path most users will take; and an error path that covers what happens when the user is unable to meet the end goal.

It sounds pretty obvious, but your user stories won't be useful if they're entirely based on gut feelings and assumptions. It's critical to get out there to conduct user story testing and collect feedback from users in the real world.

One of the best ways to ensure your user stories are actually acceptable to your users is delta testing. Delta testing lets you validate the implementation of your user stories (planned or actual) to ensure they're going to provide real value and a significant return on your investment.

Ways to test user stories:

• Once you start scoping your user stories, ask for feedback from your colleagues — and keep asking them throughout. Don't be afraid to call up some users and conduct a brief user interview.
• Make use of automated and manual testing (Acceptance Testing) from your QA teams. Instead of working in big chunks, test your acceptance criteria during your sprints as they are being completed. 
• Use delta testing to get the product's developed features in front of your target market for validation. This ensures these features are meeting their expectations and delivering the value they're supposed to. When building your project plan, look to convert your user stories into features and tasks that your testers can experience and provide you feedback on. Judge the outcomes of delta testing against your acceptance criteria to ensure your product is truly ready for release.

User story mapping is an exercise that product teams and development teams use to visualize the work that will create the overall product experience. Communicating the entire user journey with teams helps prioritize impactful features, provides context to the development team, and focuses your efforts on the value-add to the user.

Tools for visualizing user stories

There are a lot of tools out there to help you visualize and share your stories or user story map. Here are just a few of them:

• Craft.io 
• Stories Onboard 
• Jira 
• CardBoard 
• Feature Map
• Prefer working analog? Use sticky notes!

While there are no shortage of techniques and principles out there to guide you in crafting great user stories, there are three in particular that we'd like to highlight.

1. The Three C's of User Stories

This model by Ron Jeffries helps to create quality user stories by breaking them down into three components:

• Card: A physical, tangible artifact (like a sticky note) that houses the user story.
• Conversation: Throughout the project, conversations about the user story should be happening. The developers, project team, stakeholders, and users should have a voice in the use of user stories.
• Confirmation: I.E., Test it! In order to validate that your user story will deliver value and get you closer to achieving your goals, you need to get it in front of users.

2. INVEST in User Stories

INVEST is a mnemonic framework to help product teams create an effective user story, created by Agile coach Bill Wake. The idea is that user stories should be:

• Independent: User stories should not overlap or be dependent on other user stories so that they can be developed and delivered as they finish.
• Negotiable: There should be flexibility in the user story. Based on conversations with developers, users, and stakeholders, you may need to clarify your user story.
• Valuable: There needs to be a clear value to the user or intended audience of the feature or experience.
• Estimable: The work within a user story should be estimated or associated with a time (or at least a rough idea) of how long it's going to take to complete.
• Small: The stories need to be digestible and achievable in smaller time windows so they can achieve momentum. Larger stories tend to struggle to associate time estimates because there are too many variables.
• Testable: Stories need to be testable. If we can't validate if it meets the requirements, how can we ensure it will achieve user needs?

3. Shared responsibility

User stories require input and feedback from everyone on your team and the intended audience to be truly effective. Involve your colleagues in the creation and prioritization of your user stories for maximum impact, and make sure your users have their voices heard in development.

Who should be involved in this responsibility?

• Product owner / product manager
• Developers
• Scrum master / project manager
• Users or customers

Late 90s

User stories begin with computer scientist Alistair Cockburn for use within the Extreme Programming approach to software development. The first documented description of user stories defines the scope of the project from a customer perspective. 

2001

Software developer Ron Jeffries creates the Three C's formula to create user stories using three critical aspects: Card, Conversation, and Confirmation.

The "Role-feature-benefit" format for user stories was created at Connextra, bringing a critical and fundamental step to the creation of user stories:

• As a (Persona/Customer/User)
• I want to (intent or what they want to accomplish)
• So that (benefit or why they want to accomplish it)
  

2003

Agile coach Bill Wake created the INVEST (independent, negotiable, valuable, estimable, small, testable) checklist to help product teams validate their user stories will be effective.

2004

Software developer Mike Cohn published User Stories Applied For Agile Software Development, bringing a standard process to user stories.

2016

Programmer Dan North proposes "Given-When-Then," a formula for the creation of acceptance tests based on a user story's acceptance criteria:

• Given - context
• When - an action is carried out
• Then - observable consequences
  

2014

Product management expert Jeff Patton and business writer Peter Economy introduce techniques to identify, structure, and make user stories more visible in their publication User Story Mapping: Discover the Whole Story, Build the Right Product.

• https://www.atlassian.com/agile/project-management/user-stories
• https://www.productplan.com/glossary/user-story/ 
• https://hygger.io/blog/user-story-template-how-to-write-it/ 
• https://searchsoftwarequality.techtarget.com/definition/user-story 
• https://www.mountaingoatsoftware.com/agile/user-stories 
• https://en.wikipedia.org/wiki/User_story
• https://www.visual-paradigm.com/guide/agile-software-development/what-is-user-story/ 
• https://www.youtube.com/watch?v=apOvF9NVguA 
• https://www.youtube.com/watch?v=Vnf3xg3oY4A
• https://www.digite.com/agile/user-stories/