What is a user story? 

A user story is a short, simple description of product features, written with the finished product in mind and from the customer’s point of view. User stories are a few sentences, in non-technical language, that outline the desired outcome of a sprint. It should not go into detail and any requirements should be added after everything is agreed on by the developers. The typical format for a user story will address who the customer is, what they want, and why they want it.  

As a [role], I want [goal] so that [why] 

This format is not required, but it is helpful when defining the Definition of Done. The Definition of Done is a set of fixed criteria applied to all user stories and is generally “done” when the Acceptance Criteria has been met.  The Acceptance Criteria, also known as “conditions of satisfaction”, clarifies the user story and creates a set of guidelines that confirm when the story is complete.  

“A user story is a promise for a conversation”

– Alistair Cockburn 

Why create User Stories? 

The purpose of a user story is to give the customer and development team an idea of the bigger picture. Anyone can write a user story, but it is usually written by the Product Owner or a customer that has knowledge of the product, but not the development process. In scrum, user stories are added to a sprint and burned down, or completed, throughout the process of the sprint. 

A well-written user story will be completed within one sprint, anything beyond that indicates that the story was too large and should have been refined. There are many reasons a development team would want to create a user story, but we have compiled a few of our favorite.  

• Stories encourage creativity. With the end goal in mind, stories encourage critical thinking and creative approaches to solving problems.  
• Stories help a team stay focused. A well written story will have enough detail to provide context, but not so much that it distracts the team from their end goal. Short, simple descriptions are easier to manage and remember.  
• Stories allow all members of the team to participate. When a team actively works together, it allows all members to provide their feedback and unique perspective. 
• Stories can easily incorporate customer and stakeholder feedback. A tight feedback loop is essential for any product team to ensure they are delivering the right product for the customer.  

When writing a User Story, there are several things to keep in mind 

Although User Stories can seem intimidating at first glance, there are many useful tools and best practices to help guide the process. 

“The best supplements are examples; the best examples are executable, We call these examples confirmation.”

-Ron Jeffries

The Product Owner should ensure that she is using these best practices herself to create powerful and actionable User Stories while also teaching other members of the team why they are important and how to use them for their own ideas. 

When creating the User Story, first consider the 3 C’s: 

• Card – As a rule of thumb, a story should be straight to the point and small enough to fit on a card or post-it note. It should identify the requirements but does not address how to accomplish them. 
• Conversation – Requirements are largely communicated through conversation between the developers and Product Owner, who acts as a liaison between the developers and the customer. This should be detailed enough to capture functionality of the sprint.  
• Confirmation – After the Sprint has been completed and the objectives have been reached, confirmation is received from the customer or Product Owner. 

Once the User Story has been written, you’ll want to compare it against a list of criteria meant to ensure that it will fit within an upcoming Sprint and provide value to the team and product as a whole. 

In order for a User Story to be considered appropriately refine, it should meet the following I.N.V.E.S.T criteria and be: 

• Independent of all other stories. 
• Negotiable not a contract for specific features. 
• Valuable add value to the Sprint. 
• Estimable in scrum points and in time 
• Small enough to fit within an iteration. 
• Testable in principle, even if there is not a test for it yet. 

Next Steps 

Creating user stories can be difficult for even the most experienced teams, but you will have a better refinement process with these tips. 

Take this skill and use it to ensure that your product delivers the most value to your customers on a consistent basis.