User stories are the smallest pieces of work within the agile framework of software development. Their sole purpose is to describe how a unit of work will deliver value to your customer. They explain the desired outcome, functionality, and provide the development team with a clear definition of done. In Scrum, it is the Product Owner’s responsibility to translate the needs of users into clear and concise user stories, while maintaining a prioritized backlog of user stories centered around delivering enhancements or larger focused epics. I have been on the gap intelligence ProdDev Team as a Product Owner for 5 years. In that time I have written some great user stories, as well as some not so great. If you want to learn from my mistakes, feel validated in your current process, or just get a refresher, check out my five tips for writing great user stories.
1. If You Don’t Have a User, You Don’t Have a Story
As the name suggests, a user story describes how a user uses or intends to use the product. User stories should be told from the user’s perspective. Who are your users, what are their needs, their wants, their pain points? If you don’t know who your product’s users are or why they would want to use your product, then you might not be ready to write your user stories. In order to know your user’s needs and wants and ensure you are building something that they will use, do your research! Writing user stories without this vital information means that you take the risk of guessing incorrectly and wasting development resources on unused functionality.
2. Two | Find a Template that Works for You and Your Team
Lifehack: you don’t need to reinvent the wheel. Try using a user story template that allows you to plug in the 3Ws: who, what, and why. Who is this built this for? What is the specific feature being built? Why is it being built? For our team, this might look something like: As a Smartphones Data Specialist, I want to scrape Bestbuy.com smartphone listings, so that I provide our Smartphones clients with GFD (Great Freakin’ Data).
3. Focus on the Value to the User, Not the How
It’s easy to get so caught up in a flurry of feature development, that you find yourself focused on the quantity of stories delivered, rather than the value each one provides your user. As product people one of our responsibilities with user stories is to bring user context and perspective to the development cycle. Remember to focus your attention on what the user needs and why. If your user story doesn’t center the user or deliver them value, you don’t have a user story,you have a task list.
4. Communicate Like Hell
A user story is a tool, refinement is the action. You shouldn’t just be handing your user stories off to your development team. Your user stories are a tool to facilitate conversation. As a Product Owner, you and your development team should be discussing user stories together and regularly. Conversations in refinement not only allow you to share the information needed with the developers to determine a path to production, it also allows the opportunity to leverage the knowledge of your whole team in accelerating delivering value to your customers. These conversations are valuable collaboration opportunities that result in better user stories in the present and provide you as the product person with the tools to better structure future stories.
5. Embrace the Uncertainty, It Gets Easier
You may create user stories that might be too big (or too small), they might miss the mark on acceptance criteria, or maybe you lose sight of the what and steer into how territory. It happens. Much like Agile is committed to continuous improvement, so should your user story. As your skills improve you will become more familiar with addressing or defining requirements and making them measurable. Maybe you want to experiment with how to break stories into even smaller deliverable pieces (shameless plug for my colleague Michael who wrote an entire blog on just that). If you aren’t ready to take your user stories to the team or you want to get feedback, consider opportunities to help you hone your skills (talk amongst your product team or schedule pre-refinements with senior developers). We all have to start somewhere.
The purpose of a user story is to facilitate conversation. It needs to be clear, concise, and complete, all while providing enough information about who, what, and why so that developers can understand the work ahead of them, discuss potential approaches, and produce a reasonable estimate of the effort necessary to implement. A good user story is the result of team effort and isn’t a substitute or replacement for refinements, standups, or retrospectives. Creating user stories is a team sport, and like any sport you the more you practice, the better you get.
For more than 17 years, gap intelligence has served manufacturers and sellers by providing world-class services monitoring, reporting, and analyzing the 4Ps: prices, promotions, placements, and products. Email us at info@gapintelligence.com or call us at 619-574-1100 to learn more.
