Skip to content

Six Features of a Good User Story - INVEST Model

October 16, 2007 by Vaibhav

What is a User Story?

A user story describes desired functionality from the customer(user) perspective. A good user story describes the desired functionality, who wants it, and how and why the functionality will be used. The basic components of a User Story are sometimes dubbed as the three C's:

  1. Card - the written description of the story, serves as and identification, reminder, and also helps in planning.
  2. Conversation - this is the meat of the story; the dialogue that is carried out with the users; recorded notes; mockups; documents exchanged.
  3. Confirmation - the acceptance test criteria that the user will utilize to confirm that the story is completed.

A user story is not technical.

A well-written user story follows the INVEST model

Independent, Negotiable, Valuable, Estimable, Small, Testable. Let's see what each one means:

  • Independent - One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.
  • Negotiable - A user story is negotiable. The "Card" of the story is just a short description of the story which do not include details. The details are worked out during the "Conversation" phase. A "Card" with too much detail on it actually limits conversation with the customer.
  • Valuable - Each story has to be of value to the customer (either the user or the purchaser). One very good way of making stories valuable is to get the customer to write them. Once a customer realizes that a user story is not a contract and is negotiable, they will be much more comfortable writing stories.
  • Estimable - The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).
  • Small - A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. A story which is more than that in effort can have more errors associated with scoping and estimation.
  • Testable - A story needs to be testable for the "Confirmation" to take place. Remember, we do not develop what we cannot test. If you can't test it then you will never know when you are done. An example of non-testable story: "software should be easy to use".


Well-written User Stories are cornerstones for Agile Development. They should be independent of each other; the details should be negotiated between the users and the developers; the stories should be of value to the users; they should be clear enough for developers to be able to estimate them; they should be small; and they should be testable through the use of pre-defined test cases.

About the Author:



October 17, 2007 by Artem, 7 years 50 weeks ago
Comment id: 1372

Vaibhav, what could a good INVESTed user story look like? Could you give an example? Possibly an imaginary one.

Here is a quick one (maybe I

October 17, 2007 by Vaibhav, 7 years 50 weeks ago
Comment id: 1373

Here is a quick one (maybe I can add a post at a later date explaining the example a little more)

Scenario is: We are creating an online shopping site.

Here's the Card. This is THE User Story.
- The payment can be done using a credit card.
- Accept MasterCard and Visa. Consider using Amex.
- Customer should not need to specify card type.

Let's see how it is INVEST:
Independent - It is concise, not related to any other functionality and not dependent on anything else either.

Negotiable - Since the story itself is not overly detailing what needs to be done, it leaves a lot of room of conversation during development. During the conversation, notes are created and added to the card, but not at the time of defining the card.

Valuable - The requirement is in a customer-friendly tone, rather than in a technical tone. For example, we could have written something like this: "auto-detection of card type as a function of credit card number"

Estimable - There is nothing vague about this User Story. It is a fixed task which has well-defined end results.

Small - This could have been: "Integrate Online Payments using Credit Cards, Bank Transfers, PayPal, etc." Which is a much larger requirement.

Testable - There can be well-defined test cases here. Such as "Test with Visa", "Test with MasterCard", "Test with Amex", "Try making large purchases", "Test with improper Credit Card Numbers"

I hope that helped...

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of