Good user stories are vital for a Scrum project as user requirements are primarily captured in this form. Good user stories alone are not enough to ensure that the product is of high quality. However, good user stories are important to communicate user requirements to the Scrum team to develop products of a high quality.
The INVEST acronym, given by Bill Wake, suggests characteristics of good user stories. The acronym stands for Independent, Negotiable, Valuable, Estimative, Small, and Testable. Let us examine each characteristic in detail.
Independent
User Stories are often inherently dependent on each other. In such situations, it is not clear which story should be given the higher estimate. One of the solutions is to combine these stories into one, big independent story. If some of the needed functionality has already been created or implemented, then the estimate should be revised to reflect this change. Also, it is important to define a non-functional User Story that defines the pre-conditions for each dependent one.
Negotiable
User Stories should not be set in stone and should have enough scope to allow negotiation between the Scrum Team and the business team. Sometimes, the business team will have to sacrifice increased functionality due to budget constraints, or the Scrum Team might have to convince the business team to increase the budget if a critical user feature is required despite budgetary concerns.
Valuable
It is important that each feature in the backlog possess value. Saying that a feature should have value does not necessarily mean value in terms of prerogative for the end user. Some features may work in the background or may indirectly support another functionality that the user requires, so these features still possess value. This value should be clearly perceived by the Product Owner to be able to prioritize it and include it in the backlog.
Estimable
One of the characteristics of a good User Story is that it is easily estimated. The estimates do not have to be accurate, but they should be good enough to use the estimate for prioritization. Large User Stories are difficult to estimate, and small stories are generally easily estimated (we will discuss size later in the chapter). Stories that are difficult to estimate can point to underlying issues in the story—it may be that the story is too large or there is ambiguity in terms of what the User Story is.
Small
A small User Story is relatively easy to estimate. They are easier to track and can usually be completed within one iteration. Big stories take longer, and any delays take longer to report. When the Product Owner is trying to create stories that are the right size, he or she should consider the Scrum Team’s experience and capabilities.
Testable
If a User Story cannot be tested and its functionality verified, then it becomes difficult to assess whether it can be considered “done.” To verify a User Story’s testability, the acceptance criteria must be clearly defined.
