INVEST framework
Vindex scores every Jira story against the INVEST criteria — a widely-adopted checklist for writing high-quality agile user stories. Each dimension is scored independently from 0 to 100; the overall score is the mean of all six.
Where INVEST comes from
The INVEST acronym was coined by Bill Wake in 2003 as a checklist for evaluating user stories on agile teams. Two decades on, it remains the most widely-adopted yardstick for story quality — covered in every major agile certification and adopted by engineering organisations from startups to the Fortune 500. Vindex uses INVEST as the structural backbone of its scoring engine because each letter catches a distinct, commonly-occurring failure mode that the others would miss.
At a glance
Jump to a dimension
| Dimension | Most common failure | |
|---|---|---|
I | Independent | Hidden dependency on parallel work |
N | Negotiable | Implementation prescribed before refinement |
V | Valuable | Pure tech work with no user-facing outcome |
E | Estimable | Description that is a single vague sentence |
S | Small | Two or more features bundled into one ticket |
T | Testable | Subjective success criteria the team can't verify |
How scoring works
When a Jira issue is created or updated, Vindex receives the event via the Forge app and analyses the story text asynchronously. The analysis evaluates the summary, description, acceptance criteria, and any linked issues against each INVEST dimension.
Each dimension returns a score between 0 and 100. The overall score is the arithmetic mean of all six dimension scores. Recommendations are ordered by the expected lift to the overall score.
85 – 100
Strong
60 – 84
Needs attention
0 – 59
Weak
The six dimensions in depth
Independent
· IndependenceThe story can be planned, developed, and delivered without relying on another story being completed first.
Dependency chains are one of the biggest sources of sprint disruption. An independent story can be pulled into any sprint, assigned to any team member, and completed without blocking or being blocked by unrelated work. Vindex looks for explicit dependency language ("depends on", "requires story X", "blocked by") and implicit dependencies revealed by the story's scope.
Signals of strength
- ✓Story describes a self-contained user interaction
- ✓No references to other tickets or epics being required first
- ✓Acceptance criteria can be verified in isolation
Signals of weakness
- ✗Story says "after X is done" or "requires the API from story Y"
- ✗Multiple related stories must be merged before release
- ✗Shared state or data structures described across stories
Example rewrite
Before refinement
“Add the category filter UI (depends on PROJ-241 search rework and PROJ-258 category service).”
After refinement
“As a shopper, I want to filter search results by category so I can find products faster. The existing /search endpoint already accepts a category parameter.”
What Vindex looks at
- References to other tickets by key (PROJ-1234, US-0199)
- Conditional language: "after", "once X ships", "blocked by"
- Mentions of shared schemas, services, or feature flags that don't yet exist
- Linked issues marked "blocks" or "is blocked by"
Negotiable
· NegotiabilityThe story is a conversation, not a specification. The details of implementation are open to discussion between team and stakeholders.
A story is a placeholder for a conversation, not a requirements document. Negotiable stories describe the desired outcome without prescribing the implementation. Vindex scores this dimension based on how much the story constrains the solution versus how much room it leaves for the team to determine the best approach.
Signals of strength
- ✓Written as a user need ("As a user, I want…") rather than a feature spec
- ✓No specific UI layouts or implementation details mandated
- ✓Acceptance criteria describe what is verifiable, not how to build it
Signals of weakness
- ✗Story specifies exact UI elements, colours, or pixel dimensions
- ✗Implementation approach is prescribed ("use Redis", "call endpoint X")
- ✗Story has been decomposed into sub-tasks that pre-determine the solution
Example rewrite
Before refinement
“Build a dropdown using the MUI Select component with the eight category options hard-coded. Wire it to POST /api/v2/filter with a body of { category: <slug> }.”
After refinement
“Shoppers can choose one or more categories and see the result list update. Component choice and endpoint shape to be agreed in refinement.”
What Vindex looks at
- Named libraries, components, or endpoints in the story body
- Pixel- or copy-level UI prescriptions in acceptance criteria
- Sub-tasks that pre-commit the implementation path
- Absence of an outcome-framed user need ("so that…")
Valuable
· Value clarityThe story delivers clear, meaningful value to a real user or to the business — not just internal technical progress.
Every story should be justifiable to a non-technical stakeholder. If a story can only be explained as "internal refactoring" or "necessary for the next story", it likely doesn't stand alone as valuable. Vindex evaluates whether the story includes a clear beneficiary and articulates the outcome they gain.
Signals of strength
- ✓A specific user role is named ("As a site administrator…")
- ✓The benefit is stated explicitly ("…so that I can audit access logs")
- ✓Business metrics are referenced (conversion, retention, time-saved)
Signals of weakness
- ✗Story describes only technical changes with no user-facing outcome
- ✗Benefit is vague ("improve performance", "make things faster")
- ✗No "so that" or "in order to" clause explaining why it matters
Example rewrite
Before refinement
“Migrate the filter service to v3.”
After refinement
“Shoppers see filtered results twice as fast so they continue browsing instead of abandoning the search page. (Requires the v3 filter service.)”
What Vindex looks at
- Presence of a "so that" / "in order to" clause
- Named user role rather than the generic "user" or "system"
- Reference to a business metric (conversion, retention, time saved)
- Internal-only outcomes with no downstream user impact described
Estimable
· EstimabilityThe team has enough information and clarity to estimate the effort required to complete the story.
A story that cannot be estimated usually signals one of three problems: the scope is too large, the requirements are unclear, or the team lacks domain knowledge. Vindex looks for sufficient context in the description — acceptance criteria, edge cases, and constraints — that would allow a developer to size the work with reasonable confidence.
Signals of strength
- ✓Clear acceptance criteria that define done
- ✓Edge cases and error scenarios are mentioned
- ✓Story is scoped to a single interaction or feature area
Signals of weakness
- ✗Description is a single sentence with no detail
- ✗"TBD" or "to be discussed" in the body
- ✗Open-ended scope ("improve the dashboard", "fix the search")
Example rewrite
Before refinement
“Improve filtering.”
After refinement
“Shoppers can filter results by one of 8 fixed categories. Categories are returned by /api/categories. The list re-renders client-side, no SSR change. Out of scope: mobile redesign, multi-select chips.”
What Vindex looks at
- Length and specificity of the description body
- Presence of acceptance criteria that name observable outcomes
- References to known APIs, schemas, or existing patterns
- Mention of edge cases, error states, and explicit out-of-scope items
Small
· Scope sizeThe story is sized to fit within a single sprint and can be delivered as a working increment of value.
Stories that span multiple sprints create status ambiguity and reduce team velocity. Vindex estimates complexity from the story's description — the number of UI surfaces touched, data models involved, and system boundaries crossed. Stories with high scope markers receive a lower Small score.
Signals of strength
- ✓A single user interaction or workflow step
- ✓One data model or API endpoint involved
- ✓Deliverable as a standalone working feature
Signals of weakness
- ✗Story describes multiple screens or flows
- ✗Several microservices or integrations mentioned
- ✗Story uses "phase 1" / "phase 2" language suggesting it should be split
Example rewrite
Before refinement
“Rebuild the search experience: filters, sorting, saved searches, mobile redesign, and the admin moderation UI.”
After refinement
“Add a category filter to the search page. Sorting, saved searches, mobile redesign, and admin moderation are tracked as separate stories.”
What Vindex looks at
- Count of distinct screens, surfaces, or flows mentioned
- Number of system or service boundaries the work crosses
- "Phase 1 / phase 2" or "and also…" language in the body
- Acceptance criteria that read like a release plan rather than a slice
Testable
· TestabilityThe story has clear acceptance criteria that can be verified — either manually or through automated tests.
A testable story removes ambiguity about when "done" is achieved. Vindex scores this dimension by checking for explicit acceptance criteria that describe observable, verifiable outcomes. Stories without acceptance criteria, or those with vague success definitions, score lower.
Signals of strength
- ✓Explicit acceptance criteria section present
- ✓Each criterion is observable ("the user sees", "the system returns")
- ✓Edge cases and failure states are defined
Signals of weakness
- ✗No acceptance criteria in the description
- ✗Criteria are subjective ("the UI should feel responsive")
- ✗Success defined by internal code state rather than user-observable outcome
Example rewrite
Before refinement
“The filter should work well and feel responsive.”
After refinement
“Given a signed-in shopper on /search, when they click a category chip, then results matching that category appear within 1 second and the chip shows a checked state. Failure case: if /api/categories returns 5xx, the chip row falls back to a static list and an inline error toast is shown.”
What Vindex looks at
- Presence of an explicit "Acceptance criteria" heading or section
- Use of Given / When / Then or other observable patterns
- Subjective adjectives ("nice", "fast", "responsive") without metrics
- Coverage of failure modes and edge cases
Trade-offs between dimensions
The six dimensions are independent enough to score separately, but in practice they sometimes pull against each other during refinement. These are the trade-offs that come up most often.
Small vs Valuable
A truly small slice can feel low-value in isolation. The fix is to make sure each slice still delivers an observable outcome for some user — even if the larger ambition spans several stories.
Independent vs Small
Splitting a story to make it smaller often creates new dependencies between the pieces. After every split, re-check Independence: if two children must ship together to deliver value, they need to be re-merged or sequenced explicitly.
Negotiable vs Estimable
The same description that is "open to negotiation" can be hard to estimate. Vindex treats Estimable as "enough context to size with confidence", not "every implementation detail nailed down" — leaving room for the team to make decisions during refinement.
Frequently asked
?Why these six? Why not three, or ten?
Bill Wake landed on INVEST in 2003 because each letter catches a distinct, commonly recurring failure mode in user stories — and dropping any one of them leaves a class of broken story the others wouldn't catch. Two decades of agile practice have not produced a meaningfully better short list, which is why Vindex builds on it rather than inventing a new framework.
?Can a story be ready if one dimension scores low?
Sometimes. A score of 50 on Independent is often fine if the dependency is well understood and the rest of the story is strong. A score of 50 on Testable, by contrast, almost always blocks readiness — the team won't agree on "done". Use the top recommendations to decide where to spend refinement effort.
?Does Vindex penalise short stories?
No. The Small and Estimable dimensions reward concise, well-scoped stories. What Vindex penalises is missing context — a one-line story with no acceptance criteria and no user role will score low on Estimable and Testable regardless of how small it is.
?We use a different story format. Is INVEST still relevant?
Yes. Whether you write job stories, BDD scenarios, or Spotify-style bets, the underlying questions INVEST asks — is the work independently deliverable, sized to fit, and verifiable? — still apply. Vindex evaluates those properties on whatever story format your team uses.