Learn

/

INVEST

INVEST

7 patterns

Independent, Negotiable, Valuable, Estimable, Small, Testable. The compact 2003 sanity check that still catches more bad stories than any longer checklist. Testable is the letter teams fail most.

Avoid
Story
FEED-12
5 pts
Reactions on activity feed posts
User story
As ateam member
I wantto react to a post with an emoji
so thatI can acknowledge without typing a reply
Context

Blocked on: NOTIF-44 (notification refactor) and FEED-09 (feed real-time refresh).


Prefer
Story
FEED-12
3 pts
Reactions on activity feed posts
User story
As ateam member
I wantto react to a post with an emoji
so thatI can acknowledge without typing a reply
Context

Reactions update on next page reload; the real-time refresh is a separate story (FEED-15) that can ship later.

Why avoid

Two hard blocks make this story a coordination problem before it is a delivery problem. If either dependency slips, the value never lands. Independence means: redesign the slice so something useful can ship now.

Why prefer

Independence is about being shippable on its own. The right story decouples the user-visible behavior from the realtime work, so it can land first. The realtime polish becomes its own story to prioritize separately.

Bill Wake: INVEST in Good Stories
Avoid
Story
ONB-21
5 pts
New users finish onboarding faster
User story
As anew user
I wanta shorter onboarding flow
so thatI can reach the dashboard quickly
Acceptance criteria
Replace the wizard with the new wizard library
Remove steps 3 and 7 from the flow
Replace the welcome video with a tooltip
Skip email verification on staging

Prefer
Story
ONB-21
5 pts
New users finish onboarding in fewer than three minutes
User story
As anew user
I wantto reach the empty dashboard quickly after signup
so thatI can decide whether the product is for me
Acceptance criteria
Givena new signup with valid credentials
Whenthey complete the wizard
Thenthe median completion time is under 180 seconds
Why avoid

When the description specifies the library, the steps to remove, and the staging shortcut, the team is just executing. They will hit a constraint the author missed and either ship a worse solution or escalate every variation.

Why prefer

The team owns the implementation. The story sets the outcome (under three minutes) and lets engineering pick which steps to drop, which library to use, and what the tradeoff with verification looks like.

Bill Wake: INVEST in Good Stories
Avoid
Story
INF-99
5 pts
Refactor the metrics pipeline to use the new client library
User story
As aplatform engineer
I wantthe metrics pipeline migrated to the new client
so thatwe are off the EOL client before the deadline

Prefer
Story
INF-99
5 pts
On-call engineers see metrics within 30 seconds of an incident
User story
As aon-call engineer paged at 2 a.m.
I wantmetrics to appear in the dashboard within 30 seconds
so thatI can rule out an outage without waiting on the old client's 4-minute backfill
Why avoid

EOL deadlines are real. They are also a Task: the work has no user-facing value. Wrapping plumbing in story language is fine if you can name the value. If the only beneficiary is the future maintenance budget, file it as a Task.

Why prefer

INVEST's V (Valuable) is the lever that distinguishes story from task. The right ticket names the on-call engineer and the cost they pay today (waiting four minutes at 2 a.m.). That defends the work to anyone who asks why now.

Bill Wake: INVEST in Good Stories
Small
easy
Avoid
Story
SCH-50
13 pts
Schedulers manage recurring shifts across multiple locations
User story
As ascheduler
I wantto manage recurring shifts across all my locations
so thatI do not copy the same shift for each week or location
Acceptance criteria
Recurring shifts (daily, weekly, custom cadences)
Multi-location templates
Conflict detection across locations
Swap workflow with approvals
Calendar export and notifications

Prefer
Story
SCH-50
5 pts
Schedulers create a weekly recurring shift for one location
User story
As ascheduler
I wantto create a shift that repeats every Monday for a chosen location
so thatI do not have to copy the same shift for each week
Out of scope:Multi-location templates, swap workflow, conflict detection (separate stories).
Why avoid

Six features inside one story will not fit in a sprint and cannot be cleanly decomposed mid-sprint. Splitting before pulling is cheaper than splitting in flight.

Why prefer

Small means it fits in a sprint. The right story carves out the simplest end-to-end slice and explicitly defers the variations. Each deferred slice is a separate story product can prioritize on its own merits.

Humanizing Work: Splitting User Stories
Avoid
Story
PERF-77
3 pts
Dashboard loads faster
Acceptance criteria
The dashboard feels snappier
Users on slow connections do not get frustrated
Performance is improved

Prefer
Story
PERF-77
3 pts
Sales reps see today's pipeline within 1 second on the dashboard
Acceptance criteria
Givena sales rep with 50 deals on a 4G connection
Whenthey open /dashboard
Thenthe pipeline section is interactive within 1 second (p75)
p99 stays under 2 seconds for the same dataset
Why avoid

'Snappier', 'not frustrated', 'improved' are vibes. They cannot be verified without the engineer in the room, which means they will be argued about in retro and never re-tested when the next change ships.

Why prefer

Testable is the letter teams fail most. The right side gives observable thresholds (p75 under 1s, p99 under 2s) on a defined dataset. QA can verify it without asking the engineer how it feels.

Dan North: Introducing BDD
Estimable
medium
Avoid
Story
INT-32
? pts
Sync customer data with the partner CRM
User story
As asupport agent
I wantcustomer data to stay in sync with the partner CRM
so thatI am working from accurate data
Acceptance criteria
Pick a sync mechanism
Handle conflicts
Support partial failures
Work for both push and pull
Gracefully degrade if the partner API is down

Prefer
Story
INT-32
5 pts
Customer email changes propagate to the partner CRM
User story
As asupport agent
I wantthe partner CRM to show the customer's current email
so thatI am not chasing them on a stale address
Acceptance criteria
Givena customer updates their email in our app
Whenthe next sync runs (within 5 minutes)
Thenthe partner CRM shows the new email
Giventhe partner API is down for a sync
Whenthe sync retries
Thenthe change is persisted on the next successful run
Why avoid

Open-ended scope ('handle conflicts', 'support partial failures', 'work for both push and pull') is what a 13-pointer or a spike looks like. Estimating it produces a wide spread and a wrong number.

Why prefer

Three engineers can roughly agree on the right side. The scope is one field, two paths, and a defined failure mode. The left side is a research project hidden inside a story.

Bill Wake: INVEST in Good Stories
Avoid
Story
AUTH-44
13 pts
Single sign-on
Description

Add SSO. Should work everywhere. Use whatever provider makes sense.

Acceptance criteria
SSO works
Existing logins still work

Prefer
Story
AUTH-44
5 pts
Enterprise admins sign in with Okta SAML
User story
As aadmin at a company using Okta
I wantto sign in with my Okta credentials
so thatI do not manage another password for our team
Acceptance criteria
Givenan admin whose company has configured Okta SAML
Whenthey click 'Sign in with SSO' on /login
Thenthey reach /dashboard with the correct organization context
Givena user without SSO configured
Whenthey sign in with email and password
Thenthey reach /dashboard as before
Out of scope:Google Workspace, Azure AD (separate stories).
Why avoid

Vague scope, vibe acceptance criteria, and a 13 in the points field: left fails three letters at once. Not Estimable, not Small, not Testable. The story is a wish dressed up.

Why prefer

Independent (does not block other auth flows), Negotiable (the team picks the SAML library), Valuable (named admin, named cost), Estimable (one provider, scoped acceptance), Small (fits a sprint), Testable (Given/When/Then). Six for six.

Bill Wake: INVEST in Good Stories