ap.Abhishek Patel

Search

Search notes, essays, projects, and the library. Use arrow keys to choose and Enter to open.

← Notes

Agile and Azure DevOps Terminology Cheat Sheet: Every Term Explained in One Line

Practical Agile and Azure DevOps cheat sheet covering work hierarchy, planning, quality, testing, reliability, metrics, and delivery rules.

Created 2026-09-18 · Updated 2026-09-18 · 5 min read
Learningagileazure-devopsscrumproduct-deliveryuser-storiesacceptance-criteriadefinition-of-readydefinition-of-donestory-pointsestimationvelocitycapacitysprint-planningbacklog-refinementtestingtest-casesqualityinvestsreslisloerror-budgetscope-controldocumentationreferencecheat-sheet

Why this matters: half of all planning arguments are actually vocabulary arguments where two people use the same word for different things. This is the page to settle them. Each term links to the note that explains it properly.

The work breakdown

Term In one line
Epic Large business objective. Spans releases. Explained in Work Breakdown Hierarchy.
Feature Major product capability. Spans sprints. Where ownership lives.
User Story Small testable user outcome. Must fit in one sprint. Craft in Writing User Stories.
Product Backlog Item The same as a User Story, in Azure DevOps’s Scrum template. See Azure DevOps Setup.
Task Technical implementation work. A day or less.
Spike Timeboxed investigation whose output is a decision, not a feature.
Enabler Real work with no direct user outcome, written with an honest reason. 
flowchart TD
    A["Epic<br/>WHY   the business objective"]
    B["Feature<br/>WHAT  the capability"]
    C["Story<br/>WHAT  the small user outcome"]
    D["Task<br/>HOW   the implementation"]

    A --> B
    B --> C
    C --> D

The three gates

Term The question it asks When
Definition of Ready Can we safely start this? Before the sprint
Acceptance Criteria What exactly should this Story do? Written at refinement, checked at the end
Definition of Done Is this professionally complete? Before saying finished

Acceptance criteria are per Story and change constantly. Definition of Done applies to everything and changes rarely. Definition of Ready is a team practice, not an official Scrum artifact, while Definition of Done is.

Sizing and planning

Term In one line
Story Points Relative size: work + complexity + risk + uncertainty. Never hours. See Estimation and Story Points.
Fibonacci scale 1, 2, 3, 5, 8, 13. Widening gaps prevent false precision as size grows.
Planning Poker Estimate privately, reveal together, then discuss the disagreement. The discussion is the point.
Reference Story A completed Story used as the anchor for what a 3 or a 5 means in your team.
Velocity Historical points completed per sprint. A forecast, never a target. See Velocity and Capacity.
Capacity Actual availability this sprint, after leave and support duty.
Carry over Committed work that did not finish. Track it, and name the cause honestly.
Sprint Goal The one sentence objective that gives the sprint focus and lets you refuse unrelated work.
Refinement The ongoing work of clarifying, splitting, sizing upcoming items. See Sprint Planning and Refinement.

Quality and operations

Term In one line
Test case A precondition, an action, and an expected result specific enough that pass or fail is unarguable. See Test Case Strategy.
Traceability The link from test case to acceptance criterion to Story. Without it, coverage is unknowable.
Regression suite The automated tests that run every build. The asset that keeps you fast later.
INVEST Independent, Negotiable, Valuable, Estimable, Small, Testable. The Story quality check.
Three Amigos Product, development and testing look at a Story together before it is called ready.
Example Mapping 25 minute technique: collect rules, one example per rule, and open questions.
SLI What you measure in production. Example: percentage of payments that succeed. SLI SLO and Error Budget
SLO The target for an SLI. Example: 99.9% over 30 days.
Error budget The failure the SLO allows. When it is spent, reliability work takes priority over features.
Toil Manual repetitive operational work that scales with usage. Measure it, then automate it.
Postmortem Blameless write up after an incident. Actions become backlog items or it was theatre.

The rules worth memorising

  1. If a tester cannot write a test case for it, it is not a Story yet.
  2. Nothing enters a sprint without acceptance criteria.
  3. New capability from feedback becomes a new backlog item, not a bigger current Story. See Feedback and Scope Control.
  4. Urgent work enters only when something equivalent leaves.
  5. Done or not Done. No partial credit, ever.
  6. Points measure size, not time. Velocity forecasts, it does not grade.
  7. If the behaviour is not written down anywhere, the feature is not finished. See Feature Inventory and Ownership.
  8. Defend the Sprint Goal, not the task list.

The four things to measure

Not “are people busy”:

  • Carry over rate, and the named cause for each item.
  • Points added mid sprint, which is the scope growth number.
  • Stories entering a sprint without acceptance criteria, which should be zero.
  • Behaviour coverage, meaning live features with written criteria and at least one test case.

The full argument for all of this is in Why We Miss Deadlines, and the order to introduce it in is Adoption Plan.