Skip to content
Software Architecture Guide

INVEST Criteria

Explanation

Section titled “Explanation”

INVEST gives six questions to ask about a user story. A user story is a short description of something a user needs (see the article User Story). The splitting guide from Humanizing Work credits Wake with the checklist and calls it six key attributes of a good story.

Independent. Stories should not overlap in concept. The team should be able to schedule and build them in any order. Dependencies cannot always be avoided. Then a story may carry different estimates depending on order. For example, the first report costs 3 points and each later report costs 1.

Negotiable. Over time a story card gains notes and test ideas. The team does not need these details to prioritize or schedule stories. So the details stay open for discussion.

Valuable. A story must be valuable to the customer, not just to anybody. The splitting guide says this is the criterion that most often fails.

Estimable. The estimate does not have to be exact. It only has to be good enough for the customer to rank and schedule the story.

Small. A large estimate often means the story is not well understood. Someone who says the work will take more than a month often does not know what it involves.

Testable. Several teams report that they are more productive when customer tests are required before a story is built.

Where to apply it. The first step of the splitting flowchart is to check that the story you want to split meets INVEST. See the article Story Splitting for the rest of the process.

Example

Section titled “Example”

A team has the story “Users can manage their account.” Checking it against INVEST shows problems. The estimate is huge, so it fails Small. Nobody can say what “manage” covers, so it is hard to estimate. The team splits it into narrower stories, such as “A user can change their password.” Each new story gets the same six checks. Does it help the customer? Can it be ranked? Can we write a test for it?

Trade-offs

Section titled “Trade-offs”

The criteria can pull against each other. Making stories independent may not be possible, so the team may accept order-dependent estimates (f2). Making a story small is useful, but each smaller story must still be valuable to the customer, and that is the criterion that fails most often (f4, f9). The estimates only need to be good enough for ranking, so chasing exactness adds little (f5).

Checks

Section titled “Checks”
  • Stories are written so they can be scheduled and built in any order, or the dependency and its effect on estimates is stated.
  • Each story states value to the customer, not only technical work.
  • Each story has an estimate good enough for the customer to rank and schedule it.
  • Large stories are checked against INVEST before they are split.
Section titled “Related”

Sources

Section titled “Sources”