One way user stories can be viewed is as a conversation between developers and the product owner. These conversations are imperative in ensuring that developers know exactly what product they are developing and usually determine whether the user stories in a project are good. For teams with bad user stories, the acronym INVEST highlights the qualities each user story should possess, helping them implement necessary changes. INVEST stands for

Independent Edit

Independence is a significant characteristic of user stories. A straightforward way to think of independence is to think of “order independent,” meaning stories can be worked on in any order. This is important because it allows the team to independently value and prioritize every story.

Negotiable Edit

Unlike traditional requirements specifications, user stories should not be rigid rules of direction. Rather, user stories should encourage negotiation between the Product Owner and the development team to find what best suits the customer. User stories should not focus on how a requirement will be implemented, but on whether it is a feature the customer desires. The goal of meeting the customer’s needs by determining what they want should not be clouded by the temptation to detail how those needs will be met. The technical implementation should be decided by the developers.

Valuable Edit

As mentioned previously, highlighting customer value is a key part of a good user story. Without knowing what the customer values, it is impossible to prioritize the backlog and complete the user stories. Project owners that come from a traditional project management background will likely struggle with this part because they will view the

Estimable                                                               Edit

If a user story is not easily estimated, it is likely that it is too big or defined unclearly. This will make it difficult for the team to determine the complexity of the work and how much effort it will require. A story being estimable is partly a function of it being negotiable because it’s difficult to negotiate a story you don’t understand. The solution to this can sometimes be splitting the user story into smaller chunks since smaller user stories beget clearer descriptions.

Small Edit

How small user stories should be often depends on the team. A good rule of thumb is to create stories small enough so that they can be completed in a two-week sprint. The size of a user story is closely connected with whether or not the story is estimable. This is because the smaller the story, the easier it is for the team to understand all the work the story requires.

Testable Edit

User stories cannot be too subjective. In order for a story to truly be complete, it must be testable. Team collaboration comes into play here because everyone one must agree on what the definition of “done” is. A user story is considered testable if everyone is in agreement that the story can be implemented in a manner that fits this definition. The implementation should also include some kind of user acceptance test.

Following the INVEST criteria encourages good working habits and prevents the team from running into bigger problems. INVESTing in good stories allows for work to be more effective, time efficient, and increase of the overall productivity of a team.

Works Cited

Birch, Travis. “Summary of User Stories: The Three ‘C‘s and INVEST.” Agile Advice, 5 May 2015,

Hartman, Bob. “New to Agile? INVEST in Good User Stories.” Agile For All, 14 May 2009,

Rose, Doug. “Writing Effective Stories.” - from LinkedIn, 13 May 2015,

Wake, Bill. “INVEST in Good Stories, and SMART Tasks.” XP123, 17 Aug. 2003,

Community content is available under CC-BY-SA unless otherwise noted.