Blog

9 User Story Smells and Anti-patterns

  • Post author:
  • Reading time:7 mins read
You are currently viewing 9 User Story Smells and Anti-patterns

1. Thinking that everything is a user story

Many mistakenly believe that if you are Agile or using Scrum, then you must use user stories and no other format is acceptable. User stories are not required in Scrum. Product Backlog Items can take any format. User stories are a recommended technique due to some benefits over traditional requirements gathering techniques as discussed in this blog post. Don’t force yourself or your team to use them if you are not realizing these benefits.

2. Thinking that a user story is everything

Similarly, some create user stories that are several pages long because they mistakenly think that a user story is the documentation of the requirement. A user story is simply a representation of the requirement or a place holder for a conversation. It consists of a high-level description of customer valued functionality that will get fleshed out closer to implementation. Additional artifacts such as wireframes, design documents or workflow diagrams are created on an as needed basis and just in time to augment the user story and help team members develop the feature. These documents, if needed are not part of the user story.

3. Skipping the acceptance criteria

I see a lot of user stories being worked on without acceptance criteria. Acceptance criteria are important as they further help define the feature, minimize ambiguity and clarify conditions of satisfaction and completeness. User stories start at a high level with minimal or no acceptance criteria. However, as the user story is getting refined over time, acceptance criteria need to be added and refined as well. In Sprint Planning, the team does a final review of the acceptance criteria before introducing a user story into the Sprint.

4. Confusing the acceptance criteria with the Definition of Done

The Definition of Done is different from acceptance criteria. The definition of done is an auditable quality check list that applies to all user stories. It includes things like checking-in the code, verifying that unit, integration, system, and acceptance tests pass, verifying performance and load tests pass, etc… Whatever it takes to get an item to “Done” as agreed by the team. Many times, I see these listed as acceptance criteria when they should really be part of the team’s working agreements represented by the Definition of Done. This ensures the entire team including the product owner have the same understanding of “doneness” and the quality expected for all product increments resulting from user stories regardless of the specific feature.

5. Taking on stories that are too big or risky

The output of every Sprint is a potentially shippable Product Increment. Taking on stories that are too big or too complex increases the risk of reaching the end of the Sprint with a lot of items still in progress and no Product Increment to deliver.

Large user stories need further refinement to break them down into more manageable pieces. Key indicators that a user story is too large or complex are:

  1. The team cannot provide an estimate due to the number of unknowns
  2. The estimate is greater than the Sprint duration
  3. The estimate is greater than the remaining time left within the Sprint based on what has already been added to the Sprint Backlog.
  4. 1 or 2 stories take up the entire Sprint

Check out this blog post to get a better idea of right sizing a user story.

6. Splitting stories incorrectly

Stories should always represent some level of end to end functionality. Stories should not be broken down into technical stories that deliver no value on their own like just building a GUI, then building the business logic, then building the persistence logic, then integrating these stories together. Each story should include all of these combined. To learn more on how to properly split stories, check out this post.

7. Not having a Definition of Ready

Many teams regularly reach the end of the Sprint with a lot of stories in progress and no product increment. They simply move the stories into the next Sprint and continue working on them. Many of the smells and anti-patterns discussed above can be avoided if the team creates a definition of “ready” to help set a common understanding on the type of refinement needed for a user story before taking it on in a Sprint. This can include guidance on value, size, acceptance criteria, supporting documentation, etc…

8. Skipping Product Backlog Refinement

Product Backlog Refinement is an ongoing activity throughout the Sprint where the team progressively elaborates and preps future user stories for the upcoming Sprints. Many teams skip this and just create detailed user stories upfront and never revisit them again.

User stories have a life cycle where they might start out at an epic level with simply a title conveying an idea or a concept. Via Product Backlog Refinement with the team, the user story is further refined and broken down into multiple stories and further consideration is given to who/what/why. A value statement is added, an initial estimate is included along with a priority. As the stories get more and more refined, they are then split even further into smaller and smaller stories. At this point more thought is given to acceptance criteria and so forth. All along the way the team is reducing complexity, eliminating uncertainty, making the user story more manageable, getting a better handle on the implementation, and increasing their confidence in delivering a Product Increment.

9. Forgetting about the conversation

User stories are supposed to be placeholders for conversations to be had multiple times as we get closer to implementation. Always remember what the most important part of the user story is.

To learn more about user stories, check out the entire Art of Storytelling Series:

Reference and recommend resource: User Stories Applied by Mike Cohn