- User stories aren't required in Agile,
but many teams still have them.
Your story should contain a clear value statement and it
should be written from the perspective of the user.
Still, when teams are starting out,
they'll usually have a few common challenges.
So let's take a look at our task board.
As a restaurant owner,
I want to be able to print out, email,
and text my reservation list
so that we know how many people to expect.
This story isn't independent.
It has a long list of value statements.
So it's really three stories in one.
This would make it very difficult to estimate and deliver.
So let's take a look at another one.
As a customer,
I want an email copy of my receipt
so I can have it on my phone.
This story doesn't have a clear value statement.
It doesn't say why the customer
might value a copy on their phone.
So the Agile team won't have the flexibility
to find the best way of satisfying the customer.
Maybe they want a copy so they can order the same thing
next time, maybe they're keeping track of their expenses.
The team would want to know this value
so they can better deliver the product.
So let's look at one more.
As a developer,
I want to design the database tables
so that the restaurant owner
can add reservation information.
This user story probably came from a requirements document.
This is very common
if your organization is transitioning from Waterfall,
it talks about technical requirements
and it's not written from the perspective of the customer.
It also doesn't encourage a conversation
or identify any customer value.
Watch out for these common pitfalls
when working off your user stories.
If you'd like you can check out my other course,
Agile at Work: Planning with Agile User Stories.
Like many things,
your team will usually get better
at writing stories with practice.
Work closely with your product owner to make sure they take
the time to write clear stories
with a simple value statement.