User stories are short.
As a who, I want what, so that why.
That's just one sentence.
So where do all the details go?
Where do we put all of the logic, the edge cases, and the rules that are typical in a requirements document?
There is a time and a process for handling details on Agile projects, and I'm going to tell you about both in this video.
By the way, my name is Mike Cohn, I am the author of three best-selling books on agile and Scrum, including one called User Stories Applied.
I help teams succeed.
Details matter on agile projects, but instead of cramming all the details into the story itself, we capture details in two main places.
And we captured details as close to the time that we're implementing as possible.
Before we get into how we capturing the detail, I want to talk about when we captures those details.
The short answer is as closed to time when the team will work on it as possibly.
Usually that means product back or refinement meetings.
Product backlog refinement meetings are typically held weekly or bi-weekly.
Most teams aim to spend no more than 10% of their total iteration time on refignment activities, including meetings and related discussions.
While many teams prefer to hold a formal product backlog or refirement meeting near the end of the sprint, typically two or three days before it ends,
other teams may choose shorter, more frequent sessions throughout the Sprint.
It's up to you.
Experiment and see what works best for you.
So now that we know when to capture those details, let's talk about how.
Two ways.
First, the conversation.
This is the ongoing dialogue between the product owner and the team.
It's where questions are asked, ideas are clarified, and expectations are set.
The story is just the start.
the real richness comes out in those discussions.
The second way to capture details is as acceptance criteria.
A user's story should include acceptance criterion, conditions that must be met before the story is considered done.
Whether you're using sticky notes or a digital tool, there's always a place to capture a story's acceptance criteria.
These are essentially high-level test cases that define what done looks like for a Story.
Let's look at an example.
Here's the story.
As a user, I want to cancel a hotel reservation so that I'm not locked in if my plans change.
Pretty simple, right?
We add the acceptance criteria and things get more clear.
For this story, I'll add that premium members can cancel the same day with no fee.
Non-premium members are charged a cancellation fee, a confirmation email is sent to the user, and the hotel is notified of the cancellation.
Now we're talking.
The story with its acceptance criteria paints a much more complete picture of how the feature should work and gives the team something concrete to build
and test against.
All right, if you followed along in the user story reset series so far, you've seen how flexible user stories can be, from simple logins to surprise rewards
to preventing abusers.
Are you ready to dive deeper?
I've got something that can help you and your team successfully and quickly write your next product backlog or improve the one you already have.
It will also help to avoid getting bogged down by teammates who want endless amounts of details.
Click the link here or in the description to watch the next video and learn more.