The INVEST criteria for agile software projects was created by Bill Wake as a reminder of the characteristics of a good quality Product Backlog Item (commonly written in user story format, but not required to be). Such Product Backlog Item may be used in a Scrum or Kanban backlog or XP project.
In this article, we turn our attention to create good stories and focus on six attributes. However INVEST criteria relates not only to user stories.
So, a good story is:
Independent Negotiable Valuable Estimatable Small Testable
Independent
As much as possible, care should be taken to avoid introducing dependencies between stories. Dependencies between stories lead to prioritization and planning problems. For example, suppose the customer has selected as high priority a story that is dependent on a story that is a low priority. Dependencies between stories can also make estimation much harder than it needs to be. For example, suppose we are working on the ABC company and need to write stories for how companies can pay for the job openings they post to our site. We could write these stories:
A company can pay for a job posting with a Visa card.
A company can pay for a job posting with a MasterCard.
A company can pay for a job posting with an American Express card.
Suppose the developers estimate that it will take three days to support the first credit card type (regardless of which it is) and then one day each for the second and third. With highly dependent stories such as these, you don't know what estimate to give each story—which story should be given the three day estimate?
When presented with this type of dependency, there are two ways around it:
Combine the dependent stories into one larger, but independent story Find a different way of splitting the stories
Combining the stories about the different credit card types into a single large story ("A company can pay for a job posting with a credit card") works well in this case because the combined story is only five days long. If the combined story is much longer than that, a better approach is usually to find a different dimension along which to split the stories. If the estimates for these stories had been longer, then an alternative split would be:
A customer can pay with one type of credit card.
A customer can pay with two additional types of credit cards.
If you don't want to combine the stories and can't find a good way to split them, you can always take the simple approach of putting two estimates on the card: one estimate if the story is done before the other story, a lower estimate if it is done after.
Negotiable
Stories are negotiable. They are not written contracts or requirements that the software must implement. Story cards are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team. Because story cards are reminders to have a conversation rather than fully detailed requirements themselves, they do not need to include all relevant details. However, if at the time the story is written some important details are known, they should be included as annotations to the story card. The challenge comes in learning to include just enough detail.
When a developer starts to code this story, he/she will be reminded that a decision has already been made to accept the three main cards and he/she can ask the customer if a decision has been made about accepting Discover cards. The notes on the card help a developer and the customer to resume a conversation where it left off previously. Ideally, the conversation can be resumed this easily regardless of whether it is the same developer and customer who resume the conversation. Use this as a guideline when adding detail to stories.
On the other hand, consider a story that is annotated with too many notes. This story has too much detail ("Collect the expiration month and date of the card") and also combines what should probably be a separate story ("The system can store a card number for future use"). Most readers of this type of story will mistakenly associate the extra detail with extra precision. However, in many cases specifying details too soon just creates more work. For example, if two developers discuss and estimate a story that says simply "a company can pay for a job posting with a credit card" they will not forget that their discussion is somewhat abstract. There are too many missing details for them to mistakenly view their discussion as definitive or their estimate as accurate.
Details that have already been determined through conversations become tests. Tests can be noted on the back of the story card if using note cards or in whatever electronic system is being used.
Valuable
It is tempting to say something along the lines of "Each story must be valued by the users." But that would be wrong. Many projects include stories that are not valued by users. Keeping in mind the distinction between the user (someone who uses the software) and the purchaser (someone who purchases the software), suppose a development team is building software that will be deployed across a large user base, perhaps 5,000 computers in a single company. The purchaser of a product like that may be very concerned that each of the 5,000 computers is using the same configuration for the software. This may lead to a story like "All configuration information is read from a central location." Users don't care where configuration information is stored but purchasers might.
The best way to ensure that each story is valuable to the customer or users is to have the customer write the stories. Customers are often uncomfortable with this initially—probably because developers have trained them to think of everything they write as something that can be held against them later. ("Well, the requirements document didn't say that...") Most customers begin writing stories themselves once they become comfortable with the concept that story cards are reminders to talk later rather than formal commitments or descriptions of specific functionality.
Estimatable
It is important for developers to be able to estimate (or at least take a guess at) the size of a story or the amount of time it will take to turn a story into working code. There are three common reasons why a story may not be estimatable:
- Developers lack domain knowledge.
- Developers lack technical knowledge.
- The story is too big.
First, the developers may lack domain knowledge. If the developers do not understand a story as it is written, they should discuss it with the customer who wrote the story. Again, it's not necessary to understand all the details about a story, but the developers need to have a general understanding of the story.
Second, a story may not be estimatable because the developers do not understand the technology involved. For example, on one Java project, we were asked to provide a CORBA interface into the system. No one on the team had done that so there was no way to estimate the task. The solution, in this case, is to send one or more developers on what Extreme Programming calls a spike, which is a brief experiment to learn about an area of the application. During the spike, the developers learn just enough that they can estimate the task. The spike itself is always given a defined maximum amount of time (called a timebox), which allows us to estimate the spike. In this way an unestimatable story turns into two stories: a quick spike to gather information and then a story to do the real work.
Finally, the developers may not be able to estimate a story if it is too big. For example, for the BigMoneyJobs website, the story "A Job Seeker can find a job" is too large. In order to estimate it the developers will need to disaggregate it into smaller, constituent stories.
Small
Some stories can be too big, some can be too small, and some can be just right. Story size does matter because if stories are too large or too small you cannot use them in planning. Epics are difficult to work with because they frequently contain multiple stories. For example, in a travel reservation system, "A user can plan a vacation" is an epic. Planning a vacation is important functionality for a travel reservation system but there are many tasks involved in doing so. The epic should be split into smaller stories. The ultimate determination of whether a story is appropriately sized is based on the team, its capabilities, and the technologies in use.
Testable
Stories must be written so as to be testable. Successfully passing its tests proves that a story has been successfully developed. If the story cannot be tested, how can the developers know when they have finished coding?
Untestable stories commonly show up for nonfunctional requirements, which are requirements about the software but not directly about its functionality. For example, consider these nonfunctional stories:
A user must find the software easy to use. A user must never have to wait long for any screen to appear.
As written, these stories are not testable. Whenever possible, tests should be automated. This means strive for 99% automation, not 10%. You can almost always automate more than you think you can. When a product is developed incrementally, things can change very quickly and code that worked yesterday can stop working today. You want automated tests that will find this as soon as possible.
There is a very small subset of tests that cannot realistically be automated. For example, a user story that says "A novice user is able to complete common workflows without training" can be tested but cannot be automated. Testing this story will likely involve having a human factors expert design a test that involves observation of a random sample of representative novice users. That type of test can be both time-consuming and expensive, but the story is testable and may be appropriate for some products.
The story "a user never has to wait long for any screen to appear" is not testable because it says "never" and because it does not define what "wait long" means. Demonstrating that something never happens is impossible. A far easier, and more reasonable target, is to demonstrate that something rarely happens. This story could have instead been written as "New screens appear within two seconds in 95% of all cases." And—even better—an automated test can be written to verify this.