I'm trying to better understand the INVEST properties of user stories. For example, consider these two user stories:

  1. A coffee machine is programmable and it's possible to define different kind of products. A product has a unique name in the product list, a price, and some ingredients (for which is specified a quantity) choosing between coffee, milk, chocolate, and sugar. The coffee machine gives the user the ability to add, modify, or delete a product and creates a configuration with a list of products available to the customer.

  2. The user can choose a product and he can insert an amount of money equal to or greater the price of the product. If the amount is greater than the price, the coffee machine gives change to the user.

In these two stories which INVEST property can be found, and which cannot? From my standpoint this is what I think the answer should be:

  • Independent: 1 = YES | 2 = YES
  • Negotiable: 2 = NO | 2 = NO (too many details?)
  • Valuable for users: 1 = YES | 2 = YES
  • Estimable: 1 = NO (too big) | 2 = YES (maybe requires more domain knowledge?)
  • Small: 1 = NO (too big) | 2 = YES
  • Testable: 2 = YES | 2 = YES

Am I right? Is it possible to rewrite them following the 3 C's style?

  • 1. prescriptive for a single story. 2. Should be negotiable; I've seen plenty of machines that don't give change. This is not really a good Q&A style question as there are many ways to re-write your stories. Try to use a standard story format to help. As a <user> I want <feature> So that <business value> (or similar) Oct 21, 2013 at 15:23
  • Please define "3 C's style" in your context.
    – Todd A. Jacobs
    Oct 21, 2013 at 18:04
  • @CodeGnome, Card, Conversation, confirmation? Oct 22, 2013 at 8:37
  • yes @DaveHillier you're right. Oct 22, 2013 at 8:42
  • 1
    Too specific question. Not of general interest. Nov 7, 2013 at 17:47

1 Answer 1



What you have is a set of specifications, not a set of user stories. They are not the same things, and trying to apply user-story principles to specifications isn't likely to get you where you want to go.

In addition, you are misunderstanding what "negotiable" means. Negotiable doesn't mean fuzzy or ambiguous objectives; it means the details of a story (or even its inclusion in the scope) can be negotiated between the story owner and the development team for optimal results.

User Stories

User stories are independent vertical slices of functionality. For example:

As a customer
I can select coffee or milk
as my beverage base.

As a customer
I can select milk, chocolate, or sugar
as extra ingredients to add to my beverage base.

These are user stories because they have a point of view, a testable feature description, and some context. While the product has some clear dependencies (e.g. you wouldn't find it useful to vend sugar without a base beverage) implementing the selection features could be done independently.


"Negotiable" doesn't mean a story is ambiguous or ill-defined. Using an example from one of the stories above, negotiable means that the Product Owner and the Development Team can negotiate about:

  1. The priority or ordering of the stories. Perhaps it makes sense to select a base beverage before adding extra ingredients.
  2. The content of the story. Perhaps the team thinks adding Stevia to the list of ingredients is a good idea, or thinks that adding a separate "hot chocolate" story makes more sense than multiple stories about milk and chocolate.
  3. The size of a story. Maybe ingredients should each be in their own stories.
  4. The scope of a story. Maybe milk should be left out of one story or another, as adding milk as both a base and an ingredient is harder than expected because of architectural decisions made earlier in the project.

In other words, negotiability is primarily a function of the process. It is only a function of the story itself insofar as ensuring the story isn't so prescriptive that it can't be successfully implemented within a single iteration.


The INVEST mnemonic can help you write better user stories, but they aren't an iron shackle. The real issue here is that you need to fix your process so that you're actually generating user stories rather than complex, entangled specifications.

Each of your existing stories should be decomposed further, and then re-examined against the INVEST principles to see if they provide a more agile set of inputs to your project. Lather, rinse, and repeat until you've achieved a Product Backlog that meets your organizational goals and that works well with your team's development process.

  • Hi @CodeGnome. My user stories are not related to a real case but i'm doing this as an exercise for school. In particular the exercise ask to rewrite the statement in my question that are defined as user stories. Before start rewriting i have to say which of the INVEST properties the two original user stories verify. So if i have to finish my exercise i have to say that the original user stories doesn't respect any of the INVEST principle? Oct 21, 2013 at 20:07
  • @FabrizioDuroni I can't possibly guess what answer your teacher is looking for, but these are not agile user stories. If you want to know what your teacher expects your answer to be, ask him or her directly.
    – Todd A. Jacobs
    Oct 21, 2013 at 21:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.