INVEST in User Stories and Acceptance Criteria

Most people understand the concept of a user story. But there are some practices that set good user stories apart from the rest. We are talking about Acceptance Criteria and INVEST.

Acceptance criteria represent specific and defined list of conditions that must be met before user stories or features are considered complete.

The purpose of acceptance criteria is to define the boundaries for a user story / feature. Helps the product owner answer what he/she needs in order for the feature to provide value. Helps the team gain a shared understanding of the user story. Helps developers, testers and teams create tests and automation. Helps developers know when to stop adding more functionality to a story.

Good acceptance criteria has a set of characteristics. They state an intent not a solution. Are independent of implementation and are relatively high level.

Not only do good user stories need acceptance criteria but it’s recommend that they follow the INVEST acronym.

Bill Wake, author of Extreme Programming Explored and Refactoring Workbook, has suggested the use of the acronym INVEST to easily remember the six attributes of well-formed user stories.


Independent – As much as possible, care should be taken to avoid introduction dependencies between stories.

Negotiable – Stories are negotiable. They are not written contracts or requirements that the software must implement. User Stories are descriptions of features and functionality, the details of which are to be negotiated in a conversation between the product owner and team.

Valuable – The user story should be of value to one or many of the different user roles that will be using the software or purchasing the software.

Estimatable – Developers should be able to estimate the complexity of a story or the time it will take to turn a user story into working code. There are three common reasons why a story may not be estimatable:

1. Developers lack domain knowledge
2. Developer s lack technical knowledge
3. The story is too big

If the developers lack the domain knowledge they should discuss the story with the product owner so they can gain a general understand of the user story. It’s not necessary to go through all the details at this time.

If the developers lack the technical knowledge then they should not estimate the user story. Either have another developer with the skills estimate the user story and have developers pair program or send a developer on what’s called a spike. A spike is a brief experiment to learn about an area of the application. During the spike the developer learns just enough to give an estimate. The duration of the spike should be time-boxed so you can estimate the spike itself. This way the unestimatable user story turns into two user stories: a quick spike to gather information and then a user story for the work.

The team should not estimate user stories that are too big or ambiguous. It’s best to split that story into small more workable parts that can be understood by the developers and testers.

Small – As mentioned above when user stories are too big they should be split into small user stories. If stories are too big they cannot be used a sprint planning and would not be completed by the end of a sprint. User stories that are this large in size are normally referred to as epics. The epics should be slip into smaller user stories. The team will determine the appropriate size of user stories based on their capabilities and technologies used.

Testable – User stories must be written so they are testable. Successfully passing the tests proves that a story as been successfully developed. If the user story cannot be tested, how can the developers know when they are finished?

Un-testable user stories commonly show up for nonfunctional requirements, which are requirements about the software but not directly about its functionality.

Whenever possible, tests should be automated. This means strive for 99% automation. You can almost always automate more.

In summary, good user stories are Independent, Negotiable, Valuable, Estimatable, Small, Testable with acceptance criteria that properly defines boundaries, limitations and constraints.

comments powered by Disqus