Concept: INVEST Model
This concept page presents a model that defines good characteristics of user stories.
Relationships
Main Description

Even though user stories are an informal technique for capturing requirements in a lighter way, to promote interaction between teams and stakeholders, it helps to know what makes a "good" user story. The INVEST model defines them as Independent, Negotiable, Valuable, Estimable, Small, Testable. This model was introduced by William Wake [WAK03] and has been used by many other authors in the agile development-related literature.

The next sections explain characteristics of good user stories, based on the INVEST model. For more information, see [WAT08] and [COH04].

Independent

Identify and capture user stories that are as independent as possible. Independent, in this context, means that you are able to assign that user story to be completed in a defined period of time with as little dependency on other stories as it is feasible to have. You may realize that completely removing dependencies is not only impractical for some types of applications, but also undesirable. In some cases, dependencies may make sense. For example, the "Forgot user ID and password" user story depends on the existence of the "Log in to the system" user story. In this case, it makes sense to group stories into themes, which are a better way to plan for and develop together those user stories that have some level of expected dependency. (See the definition of themes in Epics and Themes.)

Another aspect of user stories being independent is to make sure that there is no functionality captured by more than one user story, which helps avoid that redundant work is done by two or more team members.

Negotiable 

Identified user stories each contain a short description of a user performing something in the system-to-be to achieve a goal. This description is initially at a low level of precision, and by no means should be seen as a contract. It is a reminder that we need to communication continually with stakeholders to understand the stories better and refine their details, based on the dialog. The trick is to capture just the right amount of detail, which may be constrained by subjective interpretation. A good sign that a user story has too much detail, too early, is when the team assumes that they already know all they need to know to develop the story without further communication with stakeholders.

As stakeholders add details to stories, team members can capture high-level design decisions to include in the stories, as well as elements that are candidate for user interfaces. But stories need to remain works-in-progress and negotiable. This means that when a team member is developing a user story, if she decides there is a better way to implement it (despite of the details captured in the user story) and still achieve the stakeholders goals, that should be option, and the stakeholders should be open to negotiating that alternative.

Valuable

This might mean: User stories need to be valuable to stakeholders. But that raises the question of "Which stakeholders? Users or owners of the system?" That depends. Some stories are written with the end user in mind, and some may be written with other types of roles in mind. Therefore, a better statement would be: user stories need to be valuable to user roles, whomever those roles represent. The easiest way to adhere to this is to write the user story from a business perspective, rather than a technology perspective, and to use natural language.

One caveat about capturing nonfunctional requirements (such as performance or availability) as user stories: These typically affect many functional user stories and should be worded in a way that expresses that dependency. See Handling Nonfunctional Requirements for more information.

From a development standpoint, the resulting implementation also needs to show value to stakeholders. It is expected that developers will implement a complete pass through all layers of the application. For example, if a developer implements all of the database access interfaces at once, this implementation may show nothing of value to an end user. On the other hand, there is much more value from a user standpoint if a developer implements a user story that "cuts a vertical slice" across the various layers of the application, meaning that the developer is really implementing user interface, business logic, and database access to support that user story.

Estimable

Valuable, agreed upon, and right-sized stories should be estimable - something that you can use as a basis for an estimate. Failure in estimating user stories size often leads to failure to deliver the solution with the value that stakeholders expect.

There are are different reasons that it might be difficult to estimate user stories size. For example, the user stories might be too broad; they might need to be broken down into smaller stories or development tasks that are more granular and easy to prioritize and estimate. Another example: the team may lack information or knowledge about the domain or technology to be used, thus they can't provide an estimate for user stories size until they have access to a domain expert or can investigate the new technology to be used.

Small

As mentioned previously, "small" stories are easier to estimate. They should also be able to be developed within a reasonably short time frame (typically with one person working for a few days to a couple of weeks), to provide value to stakeholders as soon as feasible.

The question is: how big is small? There is no right or wrong answer here, but as a general rule, there are indicators of a user story being too big. If the team has difficulty in estimating size and effort of a user story, that might mean that the story needs to be broken down into smaller stories or development tasks for a more accurate estimate to be provided. If it would take more than a month for one person to develop the user story, that's another indicator the story needs to be broken down.

Not all stories are broken down early in a project, even if it seems that they need to be. Many larger stories (also called epics), remain on the work items list as they are until it is time to develop them. At that time, the team discusses the need to break them down for the purposes of planning, estimating, and development. (Learn more about epics in Epics and Themes.)

Testable

Good user stories should be able to be tested and validated, and this needs to be true even before development begins. Understanding how to test a user story means that the user story is understood, the value stakeholders want out of it is clear, and we know when development is successfully finished. Discuss with stakeholders - and capture in each user story - the conditions that will make the user story considered fully developed.

In general, larger user stories, such as epics, are harder to test because of their size or complexity. Stories that represent nonfunctional requirements also may be hard to test, because there needs to be a clear, quantitative definition of test conditions. For example, define a test scenario that says "the administrative report needs to run in 3 seconds or less," rather than saying "the administrative report needs to run fast."