This blog post refers to a four-part series of videos on overcoming challenges with user stories. Topics covered are conducting story-writing workshops with story maps, splitting stories, and achieving the right level of detail in user stories.
To be notified when you the videos are again available, sign up below:
A common problem with user stories is how to add the right amount of detail to a story so that it is ready to be brought into an iteration or sprint.
It’s an important balancing act. Bring a story into an iteration before it is sufficiently understood and there will be too many open issues for the team to complete it within the iteration. But try to resolve every open issue and add every little detail to a story and you end up with functionality that takes far too long to make it into the hands of users.
Like Goldilocks and the bears, we don’t want stories with too little or too much detail. We want detail that is just right.
And we want that detail at just the right time, too. When detail is added to a user story is every bit as important as how much is added.. If details are added needlessly far ahead of when the story is worked on, there is a strong chance that some of those details will be wrong.
Trying to resolve all open issues in advance is costly. It can lead to rework if wrong answers are provided. It can lead to longer time-to-market as team members are stalled waiting for answers. It can also lead to a loss of creativity as programmers are merely told exactly how to implement something.
Not Everything Needs to Be Known Before Starting
When thinking about working on a user story, it is useful to realize that the team doesn’t need to know everything before it starts a story.. All open questions need to be answered before a story is finished, but not all need to be answered before the story is started.
As an example, suppose a team is working on a story such as, “As a user, I am locked out after n failed attempts to log in.” The team clearly needs to know the number of failed attempts before they call this story done. But both programming and testing can begin without that answer.
What You Can Do Right Now
In it, you get concrete advice on how you can know the right amount of detail to add to each user story. I’ll also share with you the one question I ask in every retrospective to make sure detail is being added at the right time and in the right amount.
Watch now and see how to add the right amount of detail at the right time.
This is the third in a series of videos I’ve created to help you write better user stories. But it will only be available through 11 October. So if you’re like the majority of agile teams who struggle with adding the right amount of detail, go watch the video right now. I know you’ll find it helpful.
What’s Your Experience?
Does your team sometimes struggle to add the right amount of details at the right time to user stories? How do you ensure stories are neither too vague nor too detailed? After you watch the video lesson, please share your thoughts in the comments section below.