This blog is the first post in a series about leveraging user stories to improve product outcomes. In this post, we will explore how to write compelling user stories to quickly deliver value to your customers.
The User Story – Your Key to Unlocking Product Value
Picture this. It’s demo day. You’re excited to finally see what the development team has been working on for weeks, and you’re confident this work will bring value to your customers. There’s only one problem. It’s not really what you were expecting, and it’s definitely not going to bring the value you were hoping for. So, what happened?
Chances are, if you work in product development, you have experienced this. Helping the developers understand what you want need can sometimes feel like you’re painting abstract expressionism upside down. This can get very frustrating, and not to mention, burn through valuable time and resources.
Successful product development requires effective communication with the development team. In Agile product development, the main tool we have at our disposal is the user story. This simple, yet elegant, instrument can make or break how quickly you deliver value to your customers. It’s vitally important for every product manager or owner to know how to write a great user story.
What is a User Story?
In simple terms it’s a method of communicating business requirements to a development team. What often happens in the real world though are people conflate “user story” with this thing they have to talk about in Jira or Azure Dev Ops (or name your tool). They miss the importance of what the actual user story is.
The user story is a one-line sentence that details the purpose of the work itself. The purpose of the story is to give a development team and testers clear context on the goal of the work to be completed.
The 3 Components of a Compelling User Story
There are three components to writing a compelling user story:
- User Role – a user story is written from the view of the user that wants/needs the story (i.e. health plan member, website user, etc.). The role used should be as specific as you can be to provide a clear direction to the development team on who benefits from this work.
-
Activity – this is a high level summary of what needs to be delivered with the story (i.e. submit a payment, upload a document, etc.). Similar to the user role, this should be as specific as possible.
-
Value – the last piece of the user story is the user value. This is where you write out the “why” behind the work. This gives context to the scrum team on why the user cares about this work, how it brings the end user/customer value, and how it relates to the overall product goals/vision.
How to Structure a User Story
Now that you know the pieces of the user story, there is an easy format for how to write the user story. A good user story contains the 3 pieces and is written as one sentence like below:
As a [user role], I want [activity], so that [value].
What I’ve found in my experience is many user stories leave out the value part. Either the product owner doesn’t think it worthwhile to include, or the development team feels they don’t need it. When this is left out, the team doesn’t understand the “why” behind the work. A good development team wants to know why the work they’re doing is important to the product. That can influence how they solve for the problem and code the requirements.
In Conclusion
Writing a good user story is not difficult on the surface, but you’d be surprised how many experienced product development professionals miss this foundational concept. Well-written user stories can help you communicate much more effectively, which allows your team to deliver value faster.
The next post in this series will dive into acceptance criteria.
Perficient has built innovation digital product solutions for Fortune 500 enterprises for over 25 years. Contact us today to learn more about our Innovation + Product Development services.
