kantver - Fotolia
The 7 user story guidelines every Agile developer should know
Don't let bad user stories foil your Agile software development process. Here are the seven most common user story defects and some tips on how to write better user stories.
One of the key benefits of Agile software development is its ability to reduce complex software projects into small, easily manageable user stories. User stories not only describe how a client will interact with the system, but they also provide software developers a clear and concise description of their short-term programming objectives. User stories are critical to the Agile development process and must be well written.
Poorly written user stories can doom the software development process to fail. As a result, developers need to identify and eliminate bad user stories as soon as possible. AI systems designed to examine user story guidelines and evaluate correctness have identified the seven most common user story defects. They are the following:
- ambiguity
- inconsistency
- complexity
- duplication
- omission
- testability
- size
Examples of bad user stories
Before we discuss defective and bad user stories, let's get an understanding of what a proper user story looks like.
A user story is not a use case, and it's not a system requirement. A user story is intended to be a simple description of one of the many ways a client will interact with an application, plus a simple description of how that interaction benefits the client. A simple user story that manifests itself in apps like Instagram or TikTok might be written like this:
- I want to like posts so I can have a history of my favorite videos.
- I want to like posts so I can have a history of the ones that I find interesting.
A user story statement seems simple enough, but the following defects creep into the Agile development process far too often. Let's examine how each of these defects violates the basic user story guidelines for creation.
Ambiguity
A user story should be clear to the user, the business analyst who wrote it and the developer who implements it. Don't include words that have multiple interpretations. And don't include phrases that lack clarity.
- I want to like things and view those things later.
This would be a bad user story because of its ambiguity. What things are being liked? What things are being viewed later? A user story shouldn't leave a software developer or Scrum Master with more questions than answers.
Inconsistency
A user story shouldn't conflict with itself, the epic in which it is included or the application. Take the following user story:
- I want to like posts so the ones I don't like are deleted from the system.
It makes no sense that, if a user doesn't like a post, it should be deleted from the entire system and no longer be seen by other users. That's a conflicting goal if a post is intended to be seen by many users. Another example that doesn't follow the user story guidelines is one that conflicts with the goals of the whole system.
Complexity
A basic user story guideline is that it should be simple and straightforward. If it contains too many forks or subroutines, it will be difficult for a developer to implement. Furthermore, complexity is often an indication that the business analyst didn't properly understand the use case at hand.
The following user story is an example of one that is overly complex:
- I want to like posts and have the ones I like most printed through a photo printing service and made into a book.
Duplication
When you aggregate user stories, it's not uncommon to notice some overlap. Don't waste developer clock cycles with two programmers working on two user stories that achieve the same objective. When you organize the stories into epics, filter out duplicates. For example, the following two user stories might find their way into an epic. They may be worded slightly differently, but they are, in fact, duplicates.
- I want to like posts so I can have a history of the ones I like.
- I want to favorite posts so I can have a history of the ones I favorite.
Omission
There are three parts to a user story. Each story needs a role, an action and a benefit to be considered complete. Developers must fix all omissions before they implement a user story. For example, the following story lacks a description of the user benefit:
- I want to like photos.
Testability
There's an old saying that asserts, if you can't test it, there's no point in doing it.
It shouldn't be difficult to create successful criteria that can prove whether a user story is functionally complete. If it's difficult to test a given use case, how can you expect a developer to effectively code that use case?
Each user story must be testable. If it isn't, a developer will try to kick the user story through a moving goal post. The following user story cannot be easily tested:
- I want the system to know which items I like before it shows them to me.
Size
The "size-ability" aspect of user story guidelines ties in with both the testability and complexity criteria. A user story should be a modular part of a larger epic that's made up of multiple stories. If a user story approaches the size of the epic itself, it's too large.
It should be possible to complete multiple user stories within the scope of a single sprint. If a single user story must span multiple sprints, break it down into something smaller.
A user story with a size issue tends to result in excessive cyclomatic complexity. Make your user story bite-size, not meal-size.
- I want to scan the entire database and find all entries with the letter "e" in them.
Keep these bad user story examples in mind the next time you begin a sprint. If one of these seven defects appears and you don't follow proper user story guidelines, bring it to the team's attention. It should be rectified before you go too far down the software development path.
