INVEST: the six qualities of a good user story

Problem

The story that never ends

One story has been on the team's board for three weeks: "As a customer I want payment to be convenient." The developer has changed the form twice. The designer has changed the buttons. Every time, the owner says "it is better, but it is not it".

The story is not badly written. It has a role, a goal and almost a benefit. But nobody can say when it is done, so it never is.

The idea

Six letters

Bill Wake gathered the qualities of a good story into one word: INVEST.

Letter	Means	Broken in the shop
Independent	built and shipped without another story at the same time	"I enter the code" and "I see the discount from the code": one does not work without the other
Negotiable	the details are negotiated; the story is not a contract	"a red button on the right, 120 pixels wide"
Valuable	brings something to someone outside the team	"preparing the database for promo codes"
Estimable	the team can judge how big it is	"recommendations like the big shops have", with nobody knowing where to start
Small	fits in a few days of work	"I manage my orders": cancelling, returns, history, addresses
Testable	you can say when it is done	"payment is convenient"

INVEST is a review checklist. You go through the story letter by letter and ask: is this all right? Where it is not, you have a question for the conversation.

More precisely, if you are curious

Bill Wake published INVEST in 2003 in the article "INVEST in Good Stories, and SMART Tasks". ISTQB CTFL v4.0.1 cites it in the section on collaborative user story writing.

The letter T is where QA has the most work before any code exists. A testable story is the same quality as a verifiable requirement from the lesson "The good requirement": without a measure there is no test that can fail.

Try it

Which letter?

In each story one INVEST letter is broken the most. Which one?

1. "As a customer I want to manage my orders." Inside are cancelling, returning, the order history, changing the address and repeating an old order.V: it is not valuableS: it is not smallN: it is not negotiable

2. "As a customer I want a red "Apply code" button to the right of the field, 120 pixels wide."T: it cannot be checkedS: it is not smallN: the solution is fixed, there is nothing to negotiate

3. "As a customer I want the shop to suggest products I will like." Nobody on the team has built recommendations or knows where to start.I: it is not independentN: it is not negotiableE: it cannot be estimated

4. "Preparing the database for promo codes."T: it cannot be checkedV: nobody outside the team gets anythingE: it cannot be estimated

5. Story A: "I enter a promo code in the cart". Story B: "I see the discount from the code in the cart". A without B shows nothing, B without A has nothing to show.V: they are not valuableS: they are not smallI: they are not independent

The idea

The story that cannot be checked

"Payment is convenient" is the trap from the start. Words like "convenient", "fast", "clear" and "suitable" sound like a requirement, but they do not say when it is met. Everybody reads them their own way, and the owner can always say "that is not it".

The fix is not a nicer word. It is the question "how will we know it is done?" and an answer with concrete cases:

"convenient" becomes "a new customer pays without help in under 2 minutes", checked with five people who have never seen the shop;
"fast" becomes "95 % of payments complete in under 3 seconds with 200 customers at once";
"a clear message" becomes "with an expired code, the customer sees "The code has expired" and the total stays without the discount".

Now all three (the business, QA and the developer) see the same thing. This is the third C, the confirmation, before the work has even started.

Try it

Can it be checked?

1. "As a customer I want payment to be fast." Which fix can be checked?Payment is very fastPayment is faster than the competitor's95 % of payments complete in under 3 seconds with 200 customers at once

2. "As a customer I want to see suitable products in the cart." What needs to be asked?How many products should be shown?Suitable by what? Let us give three examples of a cart and what is shown for eachWhat colour should the frame be?

3. "As a customer I want the error messages to be clear." Which version can be checked?The messages are understandable for everyoneWhen the code has expired, the customer sees "The code has expired" and the cart without the discountThe messages are well written

The idea

Small, but still valuable

Two of the letters often pull against each other. The story "I manage my orders" is valuable, but not small. If you cut it into "the orders database", "the orders screen" and "the orders service", every piece is small, but none is valuable: the customer cannot use any of them alone.

The answer is to cut so that every piece goes through everything it needs and gives something to someone. "I cancel a paid order before it is shipped" is small and valuable. How to find such a cut is the topic of the next lesson.

The letter E hints at something too. When the team cannot estimate a story, there are usually two reasons: it is too big or too unclear. Big stories are split. Unclear ones are cleared up with questions, and that is what the last lesson of the module is for.

More precisely, if you are curious

When the unclear part is technical ("can we do recommendations with our data at all?"), teams often run a short, timeboxed investigation called a spike. It is not a story for the customer. Its result is knowledge that makes the story estimable.

Exercise

Review the stories

1. Fix the story. Four stories from the last meeting. Pick the best step for each.

1. "As a customer I want a better cart." What is the best first step?Estimate the story in daysAsk what in the cart gets in the way today and write a separate story for each thingGive it to a developer to suggest something

2. "As the owner I want a 5 % loyalty discount, 10 % promo codes and the rule that the bigger one applies." What is wrong?It is not valuableIt is not small: these are at least three storiesIt is not testable

3. "As a developer I want to change the way orders are stored." How can it become valuable?Write "As the owner" instead of "As a developer"Split it into smaller tasksFind who gains: for example, the warehouse sees a new order at once instead of after 10 minutes

4. "As a customer I want to return a product within 14 days, with the system using the new returns module."N: the solution ("the new module") is inside the storyE: it cannot be estimatedS: it is not small

Test

Check yourself

1. What does T stand for in INVEST?Timeboxed: it has a deadlineTechnical: it has a technical descriptionTestable: you can say when the story is done

2. Why is N (negotiable) a strength and not a weakness?Because the story does not matterBecause the client might not payA story is an invitation to talk, and the details are decided together

3. Small and valuable often pull against each other. What helps?Cutting so that every piece still brings something to someoneDropping the need for valueCutting by layers: first the database, then the screen

4. The team cannot estimate a story. What is the usual reason?It is too big or too unclearThe story has no numberThe team is lazy

5. How is INVEST used?As a review checklist when a story is ready for a conversationAs a law: a story that breaks one letter is deletedAs a formula for an estimate in days

The good story: INVEST

Cookies