- User stories are another area
that gets 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 of 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 the 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 mentioned 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.