The INVEST Mnemonic

Basic

difficulty

Stage 2

Agile IQ® Level

Backlog Management

Practices

Agile Manifesto

Framework

Introduction

The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a backlog item.

If the backlog item fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).

Estimatable is an essential part of an Agile Mindset

Having smaller pieces of work is an important factor in getting work done in a short timeframe: "Deliver [work] frequently ... with a preference to the shorter timescale."

I.N.V.E.S.T

Written well, an item in the Product Backlog has the following characteristics:

“I” ndependent (of all others). Items could be delivered in any order, noting sequencing may be needed to account for dependencies.
“N” egotiable (not a specific contract for features).
“V” aluable (or vertically sliced) as it will make an impact for its users and help make steps toward the objectives of the Product Goal.
“E” stimable (to a good approximation) over a long series of tasks that ‘finish when they are finished’.
“S” mall (so as to fit within an iteration).
“T” estable (in principle, even if there isn’t a test for it yet) so that the end result is demonstrable and able to elicit feedback.

Actions to try

In Backlog Refinement:

Schedule a regular 1-hour Backlog Refinement event per week.
Discuss how many Product Backlog items are likely to fit into the next 2-3 Sprints.
Assess whether those Backlog items meet the INVEST criteria.
If the Backlog items don’t meet the INVEST criteria, start some research, high-level design, and discovery workshops with members of the team or even stakeholders.
Apply what you’ve learned and document it against the Product Backlog items.
Stop when you have about 2-3 Sprints worth of well refined items.

Clarify scope. Don't do design work.

The purpose of Backlog Refinement should be to confirm the scope of work, not to undertake traditional design and requirements documentation work.

Anti-patterns: Backlog items aren't requirements

Backlog items should be written to a sufficient level of detail to enable the team to start work on them. They are not, in this way, similar to traditional requirements documentation. Requirements documentation is done to the level that (a) business stakeholders can agree (and sign-off) on what they will get, and (b) indicate a complete solution, prior to any work being done.

All fields are required.