This article is part of the Effective User Stories Series.
If you’ve missed reading
- Part I: Why User Stories,
- Part II – What Are User Stories,
- Part III – How To Write Effective User Stories, or
- Part IV – Who Is The User
we strongly recommend you check them out first.
In the previous posts, we’ve given you some invaluable guidance on how to utilize User Stories for maximum benefit. It is equally important to make sure you’re not falling into the most common mistakes many teams do when working with User Stories.
User Stories Common Mistakes
There are many mistakes that you should avoid when working with User Stories and here we’ll discuss the most common ones we’re observing in our practice:
- The Solution is “Locked”
- Fake User Stories
- Missing User Benefits
- No Value For The User
- Too Many Details
- Too Few Details
- Information Is Not “Just in Time”
The Solution is “Locked”
One of the most common mistakes when creating User Stories is when the solution to the problem is given in advance or “locked”. When this happens, the development team is prevented from being creative and unable to unleash their full potential.
Example:
Title: User Login
Description:
In order to use the system functionality fast,
as a new customer,
I want to be able to login with my Google account.
Here the solution is clear – provide login via Google, but what if there are better ways to enable customers to use the system functionality fast? This may never be discussed and an opportunity to satisfy the user needs better is lost.
Fake User Stories
Example:
Title: User Data Storage
Description:
As a developer,
I want to have column X in table Y in DataBase Z,
so that I can store the user data.
Many people believe that the Product Backlog consists only of User Stories. This is not true. There may be all kinds of backlog items, like Bugs, Spikes, Technical Tasks, and others.
The example above is not a real User Story, but a technical task in disguise. We try to put a fake User Story in the Backlog, using the User Story template.
Missing User Benefits
Example:
Title: User Photo Upload
Description:
As a customer,
I want to upload my profile photo.
The “so that” part is missing. It is not clear what is the value for the customer and as we discussed in the previous post, it’s crucial for the success of the Story. You will never end up in this situation, if you use the “Start with Why” template.
No Value For The User
Example Story 1:
Title: Backend: User Login
Description:
In order to use the system,
as Anna
I want to be able to login into the platform.
Example Story 2:
Title: UI: User Login
Description:
In order to use the system,
as Anna
I want to be able to login into the platform.
User Stories should be “vertical slices”, providing full functionality and value to the user.
In the example above, the two items are not real User Stories. Splitting the backend and UI is considered meaningless because the real value for the user is only provided when both of them are done. Neither completed Backend, nor a UI item will make it possible for the user to start using the functionality.
The two items are technical tasks for a real User Story.
The good practice is to have one User Story under which to add sub-tasks for Backend, UI, Design, QA or another type of work. By doing this, we can easily track the progress over the defined functionality.
Too Many Details
Some Product Owners tend to include too many details in the User Stories and as we pointed out at the first article, the User Stories should not be turned into full product documentation. Their purpose is to give just enough information and to provide it just in time.
Example:
Title: Sign in with Facebook
Description:
In order to follow my friends’ activities,
as Mary
I want to be able to sign in to the platform using Facebook.”
Context: As we discussed in a meeting on 03.12.2019 with John, Jason, George, and Lyssa, we agreed to use Facebook as our primary SSO approach. It is not clear if we are going to also have Google Sign-in because we have many users that may not have Facebook accounts.
Maybe we need to schedule additional meetings to clarify how many social platforms we will use.
We need to contact Garry, who is on the Tiger team that has done such integrations in the past for the Phoenix system.
Acceptance Criteria:
- After signing in using Facebook Mary’s profile image should be automatically imported.
- Mary should automatically become a follower of all her Facebook friends.
- Mary should be able to turn on/off the auto-sharing of her activities.
- A confirmation email should be sent to Mary’s Facebook mailbox to confirm that she signed into our platform.
- If Mary does not confirm within 1 hour that she signed in to our platform, then:
- Mary’s account on the platform is removed.
- We send an additional email to Mary’s mailbox to inform her that we do not store any of her data on our servers anymore.
Additional Notes:
Michel, please provide the needed designs until next Wednesday.
User Stories written like this are very hard to read and make it impossible to serve as a starting point for a productive team discussion.
Too Few Details
Example:
Title: Sign in with Facebook
Description:
Empty
Acceptance Criteria:
Empty
We may have the opposite problem of having too many details – having too little. Both extremes are not helpful for the Agile Team.
Information Is Not "Just in Time"
Think about the following scenario: You are a team in the middle of a Sprint and you committed to delivering a User Story that has some unknowns. The time passes by, but the Product Owner could not give you the needed details until the day before the end of the iteration.
You now have the necessary information, but you can not complete the work, because the details were NOT given to you just in time.
To avoid such situations, we recommend the team define and commit to a clear Definition of Ready (DoR), that every User Story needs to pass before being added to the Sprint.
Conclusion
Writing effective and powerful User Stories is a challenge for many teams. Following the provided guidelines is going to help you to establish a strong foundation to build your Product Backlog. However, have in mind that like any other Agile practice there is no single “best” way to use it. Your team needs to adapt and experiment with how they embed the User Stories into their Ways of Working based on their unique context.
