Most User Stories Are User Fairytales 🧚♀️
Don't Reverse Engineer User Stories From Features You've Already Decided to Build
You've decided to build a big feature. You then decide to capture the feature you want to build in the shape of User Stories.
Oh boy, you're missing out and setting yourselves up for failure 🤯. That's precisely what you shouldn't be doing.
You are now the proud owner of a Product Backlog with none of the benefits of User Stories, and all of their downsides.
You'll be working with a forced format where you must shoehorn and reverse engineer the 'User Stories' from the features you've already decided to build.
You're not doing 'User Stories', you're making 'User Fairytales'.
You might be wondering, what should you be doing instead?
1. User Stories should be rooted in the real world. Talk to users, understand their world and gather evidence. That's what you should describe with your User Stories.
2. If you have to think long and hard how to write something in a User Story, then you're probably not doing User Stories. The User Story format should be used to capture something you already know. Writing User Stories becomes hard when you have to describe something you don't know because you're reverse engineering it from a feature that someone else conjured.
3. You don't have to split up User Stories into more User Stories. The moment User Stories become forced and you are busy describing how the feature is supposed to work by shoehorning it into a template that's meant for understanding what the user is trying to achieve, then you probably shouldn't be using a User Story.
TDLR: keep it real. Work with User Stories, don't do User Fairytales 🧚♀️ .
Working with User Stories rather than User Fairy Tales is a better way to achieve happily ever after in you product.
Without thinking too much about it I've been doing both. To me it just comes natural to start with the User Story. In some cases, mostly with big technical topics I might start with the Feature and it's probably because I need the structure.
I’m finally beginning to break the thinking pattern for our team by working backwards from the problem (the user story). It’s difficult to get away from those patterns when we have frameworks like SAFe that induce them. I’ve seen those frameworks be used to create solutions, instead of organizing work - which is what they’re really intended for. Thanks for the write-up!