Writing user stories is a basic product management skill, and you should know how to do it. Really, you should. Because it's not that hard, I promise.
As a software PM, you should be writing, tweaking, and managing user stories daily - and hopefully pushing some (most?) through to production.
I've been asked by numerous product managers, business analysts, developers, and designers how to write a good user story. So I'm going to give you my secret sauce.
Here's my 4-step template.
- Here you should write the business case, short and sweet.
- EX: "Currently, we don't have a "buy now" button on the product page, and we really need to add this so that users can purchase items on the site."
- This is the actual user story. I've actually seen very few PM's actually write out stories in this standard format, but it does help with the "why" of the user story, which you'll get asked for often.
- EX: "As an end-user, I'd like to be able to click on a Buy Now button on the product page, so I can purchase that product.
Conditions of Satisfaction:
- This is the stuff that, from a product standpoint, should happen once the user story is complete.
- Conditions of Satisfaction can be "translated" into simple unit tests for your testing team.
- The end user sees the Buy Now button on the product page
- The button should be green with white text
- When the user clicks the Buy Now button, she adds the product to cart, and can see the product in the cart if she navigates to the cart page
- Sometimes (OK - let's be honest - MOST of the time), in the real world, you don't have ALL of the details when you write a user story. That's OK. But you should outline any risks or unknowns that still need to be scoped out.
- EX: Still need final assets from design
That's it! If you write out your user stories in this organized format, your dev team will love you, and you will find you can send lots of different stakeholders to your user stories to explain what's being built.