Many Scrum Teams struggle to bridge the gap between the Product Roadmap and Product Backlog and might be overlooking the User Story as a powerful tool to accomplish this goal.
User stories are simple descriptions of a product feature written from a customer’s point of view that outlines the final product. This crucial tool links together the user, the user’s needs, and the reason why they want it released. Creating user stories helps with creativity and focus as well as incorporating team member and customer feedback.
Read on to learn more about what a user story is, why you should create them, and helpful tips for doing it right.
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. These stories should not go into detail, and they should add any requirements after the developers agree on everything. 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?
A user story aims 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 knows the product, but not the development process. In scrum, user stories are added to a sprint and burned down, or completed, throughout 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 team members 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.
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.
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 consistently.