Crafting a Perfect User Story
PRDs, User flows— Needed by Product folks to create User Stories. When written correctly, it sparks conversation within an Agile team enabling them to understand about the end user.
In the process of “crafting” a perfect user story, we often think about all the possible requirements and go with the assumption that the tech team will simply glance through it and start coding. But, did we at least test if the rest of the team understands “why” they are doing it?
Going back to the good old Agile commandments, here’s one that does make sense for this context.
Individuals and interactions over processes and tools
I’m not advocating that we don’t write user stories at all. But the focus should be more on the folks who read and act upon the story.
User Stories vs Use cases
User stories are about needs. Use cases are about the behavior you’ll build into the software to meet those needs.
User stories are great means to communicate what’s needed from the feature. As per this article, it explains clearly the basic difference between Use Case vs User Story.
User stories as conversation starters
These days we are obsessed with crafting a perfect user story and sometimes we forget the essential part — Did the team understand “why” they have to build it and “How”?
User stories should engage in great conversations with the right people who are equally committed and interested to get it done.
Before filling up the backlog, let’s think about the interactions of the feature. Pick up a tool or whiteboard or even a piece of paper and start drafting out “why” are you building this feature. Now, do get too nerdy about APIs, DB tables, etc., Instead. focus your efforts on explaining the dependencies more from an end user flow point of view.
Next all the possible interactions about the feature. Bonus tip — Pull in your tech lead/team + Scrum/Project person into the conversation. After you draft it out, the team who’s gonna build it will get a general idea of “what” they are supposed to build. This will ensure their buy-in.
If you’re wondering how it’s done, then here are some time tested / most used ways to do it:
- “Who” are you building this for — Decide and know about the “user” this feature is intended for. User Personas will help you get clarity.
- Discuss the “Why” — Share your thoughts on the importance of the feature. Back your idea with data like metrics, user interviews, reviews, etc., and tell them how the “idea” might work.
- Brainstorm on “How” — Understand their thoughts on how to implement your idea. Let the team bring their ideas to the table. You might be surprised by their ideas.
- “Stop” the flood — Ideas are good, but you need to decide on the best approach, and remember, you can’t satisfy everyone. If you can’t decide now, it’s totally fine. Get back with solid reasons on why a certain option was chosen. Lots of good frameworks out there to help you out on this.
- “Collect” the feedback — Ask the team about how they felt about this whole exercise. Good/Excited/Bad, take their inputs.
The perfect user story
Let’s see what we have now:
- Clear user flows
- User Personas
- Clear context about “Why” and “How”
- What success looks like
- Acceptance criteria
- And most important clarity and Team buy-in
Final Thoughts
- Focus more on the value your team and how collectively you can solve the problem.
- Focus on conversations instead of perfecting user stories.
- Focus on quality instead of quantity.
Like to share some feedback?
If you’ve read this far, I hope you found it useful. If you’ve any feedback for me, please do share. Thanks in advance.
