| name | invest-check |
| description | Load when reviewing, writing, or assessing acceptance criteria for a user story or work item. Provides the INVEST checklist and evaluation framework. Do not load for general requirements questions, dependency analysis, or language review.
|
INVEST Acceptance Criteria Review
You are now running an INVEST-focused acceptance criteria review. Apply this framework
to the acceptance criteria in the current work item or requirement.
The INVEST checklist — evaluation guide
I — Independent
The story can be built and released without requiring another unfinished story to be done first.
Check: Can a developer pick this up without waiting on another team or story?
Red flag: "After story #42 is done, this story should also..."
Fix: Split, reorder, or remove the dependency. If the dependency is unavoidable, note it
explicitly as a blocking relationship in ADO — don't hide it in the story text.
N — Negotiable
The story describes what the user needs, not how it should be built. The team has room
to decide the implementation approach.
Check: Does the acceptance criteria prescribe a UI layout, a specific table, or a
particular code approach?
Red flag: "The system must use a new table called 'Approval Entries'"
Fix: Rewrite to describe the outcome: "Approval history is visible on the document and
shows who approved, when, and at what amount."
V — Valuable
The story delivers something a real user or the business cares about.
Check: Is the value explicit? Can you point to a specific user role who benefits?
Red flag: Technical stories written without a user benefit: "Refactor the posting codeunit"
Fix: Add the "so that" clause: "...so that posting completes 40% faster for month-end runs"
E — Estimable
The team has enough information to size this work.
Check: Would a developer be able to estimate this in story points without asking more
than two clarifying questions?
Red flag: Acceptance criteria that reference undefined external systems, unknown data volumes,
or unresolved design decisions
Fix: Answer the open questions in the story before bringing it to sprint planning. A story
that can't be estimated shouldn't be in the sprint.
S — Small
The story can be completed in one sprint.
Check: Would a single developer (or pair) be able to finish this, test it, and get it
reviewed within the sprint timebox?
Red flag: Acceptance criteria with more than 5–7 distinct scenarios; stories that touch
more than 2–3 base app objects; stories that span multiple user roles
Fix: Split the story. A good split preserves value in each piece — vertical slice,
not layer by layer.
T — Testable
There is a clear, unambiguous way to verify the story is done.
Check: Can a tester write a test case right now based on the acceptance criteria alone?
Red flag: "The system should handle it correctly", "user-friendly", "appropriate"
Fix: Rewrite each criterion as a specific Given/When/Then scenario. If you can't write
the scenario, the criterion isn't testable yet.
How to produce the INVEST assessment
For each principle:
- Quote the relevant acceptance criterion (or note "no AC present")
- Give a verdict: Pass / Flag / Fail
- If Flag or Fail: one sentence on the specific problem and a concrete suggestion
End with:
INVEST SUMMARY:
I: [Pass/Flag/Fail] N: [Pass/Flag/Fail] V: [Pass/Flag/Fail]
E: [Pass/Flag/Fail] S: [Pass/Flag/Fail] T: [Pass/Flag/Fail]
Ready for sprint planning: [Yes / No — one sentence on the biggest blocker]
