Search code examples
extreme-programminguser-stories

User stories - INVEST Principle

I'm trying to undestand better the INVEST properties of user stories. For example consider this two user stories:

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

  2. The user can choose a product and 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 this two stories which INVEST property can be found? which not?

From my standpoint this is what I think could be:

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

Am I right? Finally do you think that it's possible to rewrite them following the 3 C's style?

Solution

  • In my opinion, a good user story for team to work with should be done in the "INVEST" format. But, to remind the benefit of user story, it should follow 3 C's style. If the user story doesn't have card, conversation, and confirmation, it loses the point of user story.

    In my team, we try to write user story using "INVEST" (with user story format as a/I want to/so that), then we will have "conversation" about it. During this session, we know that the "card" is in the good shape or "INVEST" or not. Then, we "confirm" that the card is good to go for the sprint.

    Some teams don't focus to make the user story to be "INVEST" or in user story format because they focus on "conversation" of the cards. So, the format could be anything that team agrees on.

    From time to time, your team will figure out what is the best user story format for them. It will just happen naturally.

    So, I think there is no silver bullet for this. Just remember that the user story or the item (any name you wanna call) is something that your team agrees on and is comfortable to work with it. Making the decision is not up to one person but team.