User stories are another area that get a lot of attention. Product owners have anxiety around creating the best possible user stories. This is especially true for product owners who were once business analysts. A business analyst spends a lot of time writing the clearest possible project requirements. That’s because clear requirements will cause less problems down the road.

But user stories are completely different. There’s a form and format to the stories but this is not nearly as formal as project requirements. A user story is more like a placeholder for a future conversation. Remember that agile teams encourage face-to-face communication. They don’t rely on documentation. This is the sixth principle and second value in the agile manifesto. So user stories aren’t about getting the right format, they’re much more about having the right conversation.

With that being said, there’s still a common format for user stories. Typically it’s as a user, I want some feature so that I can get some value. So you might have a user story that says something like, as a restaurant owner, I want to be able to put my menu online so that people will be interested in my restaurant.

Remember that the format of the user story forces the product owner to think about customer value. It’s the last line in the story. You also might notice that there’s nothing here about functionality. The restaurant owner doesn’t talk about upload buttons or databases, they just care about the value.

In this story they want to encourage people to come to their restaurant. So that means that the product owner should have a future conversation with the team to deliver that value. In scrum this is often called the difference between the what and the how. The product owner worries about what the customer wants and the development team decides how to deliver it.

Now there’s nothing in the Agile Manifesto that says the team needs to work off of user stories. There’s also nothing in scrum that mentions user stories. The user story is just a popular way for the team to communicate and stay focused on value. The most important thing to remember is that user stories are not just an agile version of requirements. I see a lot of product owners get into trouble by taking a requirements document and breaking it down into user stories. Remember that requirements are designed to limit the conversation.

A good requirements document will be very clear and tell the developer exactly what to do. User stories are a note to have a future conversation. It isn’t designed to show the answers, instead it helps the team ask the right questions. Sometimes Agile teams will come up with a better way to deliver value. One that the customer hadn’t even thought about. It’s this conversation between the customer and the developers that keeps the team focused on value.