About Roman Pichler

Roman is an agile product management expert. He helps companies create new products by providing consulting and training services, and he is the founder of Pichler Consulting.

5 Common User Story Mistakes

User stories are a simple, yet effective way to communicate how a user or customer employs a product. But writing user stories that help a team build great software can be challenging. The following list summarises five common user story mistakes to help you improve your stories.homer-simpson-doh

Story Mania

Some product owners and teams are so fond of user stories that everything is expressed as a story. This either results in some rather odd stories – stories that capture the user interface design, complex user interactions, and technical requirements; or these aspects are simply overlooked.

Like any technique, user story writing has its strengths and limitations. I find stories particularly well suited to capture product functionality, and when applied properly, nonfunctional requirements. But user interface design and complex user interactions are better described by other techniques including design sketches, mock-ups, scenarios, and storyboards. Complement your user stories therefore with other techniques, and don’t feel obliged to only use stories.

User Incognito

A user story tells a story about a user interacting with the product. Some stories, however, omit the beneficiary altogether, or they talk about a mysterious user as in “As the user, I want to …” But if it’s not clear who the user is, why should the story be developed? How can we be confident that the story will benefit someone?

Make sure you that all your stories have a clear user or customer. As I like to work with personas, I use personas in my stories (instead of user roles). This connects each story to the right persona, and it allows me to understand if and to which extend the story addresses the persona’s need or goal. To achieve this, I use the following template: As <persona>, I want <something> so that <benefit>.

Disastrous Details

The devil is in the details: Some stories are too big and vague for the team to understand and implement. Others contain too much detail, or even prescribe a solution. Getting the details right seems to be a battle the product owner can only loose.

My recommendation is: Start with big, coarse-grained stories called epics particularly for all new features. Epics allow you to capture an idea without committing to the details. Then break an epic into more detailed user stories. The new user stories replace the epic, and they provide more information about the product’s functionality. Pay particular attention to the user stories that are pulled into a sprint. These stories have to be ready: clear, feasible, and testable. (You can learn more about decomposing epics into ready stories in my post “Epics and Ready Stories”.)

Progressively refining your stories keeps your Product Canvas or backlog concise, it makes it easier to integrate new insights, and it reduces the effort required to stock your initial canvas or backlog. This is particularly valuable for new products and new features. Make sure you do not prescribe a solution in your stories. Rather focus on the “what”, nor the “how”. The latter is best captured in an architecture diagram.

Story Handoff

Some product owners diligently write user stories, and give them to the development team in the sprint planning meeting. This handoff is usually suboptimal, as it wastes the team’s ideas and knowledge. Stories can hence be inappropriate, difficult to understand, not feasible and testable.

User stories, however, are not meant to be standalone documents. They should be complemented by a conversation between the product owner and the team, or even better: written collaboratively. A story wants to capture the essentials, and not specify every detail: The latter would be difficult for new features and too slow and too expensive in an agile / lean context.

User story writing should be a team effort, where product owner and development team create the stories together. Allocate time for a collaborative Product Canvas workshop or backlog grooming meeting, particularly when you develop a new product or new features. Trust me: Better stories and a better product will be your reward.

Criteria Crisis

Acceptance criteria are maybe the most misunderstood part of users stories. I have seen detailed stories with no acceptance criteria, criteria that restate the narrative, and criteria that hide new stories, or even contain entire workflows. The last two mistakes are exemplified by the following story (the narrative is on the card on the left, the “acceptance criteria” on the right):

The idea behind acceptance criteria is simple: They allow you to describe the conditions that have to be fulfilled so that the story is done, that it can be exposed to the users and the other stakeholders. This ensures that you gather feedback and/or release features, and it helps the team plan and track their work: The criteria enrich the story and make it more precise and testable. (The criteria all stories have to fulfil such as “online help is available” are not stated in the acceptance criteria but in the Definition of Done.)

As a rule of thumb, I like to work with three to five criteria per story, and I am not worried if my epics don’t have acceptance criteria to start with. Ready stories, however, must provide meaningful criteria. You can find sample acceptance criteria in my posts “Epics and Ready Stories” and “Nonfunctional Requirements“.

Summary

“I don’t hate you for failing, I love you for trying,” says Marge to Homer Simpson. We can all tell and write good user stories; we just have to practice it. And practice makes perfect, as they say.
 

Reference: 5 Common User Story Mistakes from our JCG partner Roman Pichler at the Pichler’s blog blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


five × = 15



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close