Crafting user stories is an art. And like any art, the more you do, the better you’ll get at it. Writing stories in a silo without feedback, from peers, seniors, and the development team alike would be pointless. A circlejerk of one.
Like many art forms, you develop your styles for writing user stories. I’ve seen so many in my experience that it is fascinating to see why those formats work and how they’re implemented.
Like all art forms, there are certain rules — bendable — but for 90% of the cases, hold. As a product manager, you’re expected to adapt to your team, your product, and your organization (in that order) to craft effective user stories.
I will NOT go into specifics of writing user stories. There are many authors out there who’ve done an excellent job of formulating one (list at the end). Instead, I’ll focus on using the stories you’ve crafted effectively, and how you can improve them if needed.
This article isn’t for beginners — but PMs with 2–5 years of experience. There are a few things a new PM can learn, but it’s best if you get your basics figured out through other articles (I’ll list some at the end).
Definition of a User Story
Traditionally, user stories are defined based on how they’re used:
And these are good and very functional. However, to anyone crafting new user stories, they do not provide any guidance as to how they should go about it.
To any of the above, I’ll add my two-cents:
A user story serves as a description of intended user behavior and expectation within a bigger story timeline. It also serves as a contract amongst three parties: The development team, Future consumers of the stories, and you.