Question

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?

Was it helpful?

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.

OTHER TIPS

You have highlighted many of the issues with your attempt at defining the User Stories.

As you have become aware, getting a User Story to match all of the INVEST principles can sometimes be tricky. These principles targets to aim for, so do not worry if you cannot match them all.

Getting a User Story to be truly independent is often the most difficult to principle. I would recommend on getting your User Stories to a small enough size that your team is comfortable estimating. As Stories get larger they get exponentially harder to estimate and there is a greater chance of misunderstandings.

Teams often combine User Stories with planning poker, an Agile Estimation technique. This can help in knowing when a User Story needs to be broken down further. For example, many Scrum teams will not pull in Stories that are above 13 points and will often try to break down 13 points stories to 8's and 5's.

The 3 C's there to remind you of what is important when practicing User Stories. Mainly the conversation and collaboration element. This is not a format as such.

As explained previously, a User Story should be a defined as;

As a (role) - This can be an end user or a business proxy

I want - A description of what need to be done

So that - the definition of the value

You should then use acceptance criteria to define the inner workings. Business rules, etc.

By practicing to this format your User Stories will match the INVEST principles better. Just do not forgot, defining User Stories is not a solo activity.

Hope this helps.

P.S your questions on User Stories might be better suited to pm.stackexchange.com.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top