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

Created · Updated · 5 min read

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.

This connects to

Epic vs Feature vs User Story vs Task: How to Break Work Down and Decide Which Is Which

Four levels, and each one answers a different question:

Note

How to Write a User Story That Fits in One Sprint: INVEST, Splitting Patterns and Examples

The most useful thing I ever read about User Stories is Ron Jeffries' idea of the three Cs: the Card (the short sentence), the Conversation (the discussion it triggers), and the Confirmation (the acceptance criteria you agree on). The written sentence is not a specifi

Note

How to Set Up Azure DevOps for Agile Delivery: Work Items, Fields, Tags, Queries and Test Plans

A warning first: the tool does not create the discipline. A perfect Azure DevOps configuration with no [[How to Write Acceptance Criteria|Acceptance Criteria]] and no [[Definition of Done, The Gate Out of a Sprint|Definition of Done]] produces a beautifully organised record o

Note

Definition of Ready: The Checklist That Decides Whether a Story Can Enter a Sprint

The Definition of Ready is a short checklist a Story must pass before it is allowed into a sprint.

Note

How to Write Acceptance Criteria: Defining Expected Behaviour Before Development Starts

Acceptance criteria are the specific, checkable conditions a single [[How to Write a User Story That Fits in One Sprint|User Story]] must satisfy to be accepted. They belong to that one Story and nothing else.

Note

Definition of Done: How to Stop Calling Work Finished When Testing Is Still Pending

The Definition of Done is a single shared checklist that applies to all work, describing what must be true before anything can be called complete.

Note

Story Points Explained: What They Measure, Why Fibonacci, and How to Run Planning Poker

If you write "1 point = 4 hours" on a whiteboard, you have not adopted story points. You have invented a complicated way of writing hours, and you have kept every problem hours had while adding a translation step.

Note

Velocity and Capacity: How to Forecast Delivery Dates With Evidence Instead of Optimism

People mix these up constantly, so start here:

Note

The Sprint Cycle Explained: Backlog Refinement, Sprint Planning, Daily, Review and Retrospective

If you take one thing from this note: the quality of your sprint was decided before it started.

Note

Why Features End Up With No Test Cases, and How to Make That Structurally Impossible

That is the part worth understanding. There was never a meeting where we chose to ship untested features. What happened is that testing sat outside the definition of finished, so under pressure it was the thing that quietly did not happen, two hundred separate times.

Note

SLI, SLO and Error Budgets: Measuring Whether Your Product Is Actually Healthy in Production

A feature can pass every test case and still be failing customers, because tests run in a controlled environment on clean data with one user at a time.

Note

Scope Creep in Sprints: How to Classify Stakeholder Feedback Instead of Absorbing It

A Story was agreed: export invoice as PDF, 5 points, acceptance criteria written.

Note

Why Nobody Remembers How a Feature Works: Documenting Behaviour, Edge Cases and Ownership

Right after you build a feature, you know everything about it. Every edge case, every reason you chose one approach over another, every weird case the stakeholder mentioned once.

Note

Why Startups Keep Missing Deadlines: The Real Cause Behind Sprint Delays, Missing Test Cases and Forgotten Features

Sit in any startup review meeting and the same questions come back every month:

Note

How to Roll Out an Agile Delivery Process in 90 Days, One Change at a Time

One change at a time. A team can absorb roughly one new habit per two weeks. Introduce six at once and you get six half followed rituals and a team that concludes "process does not work here", which then blocks the next attempt for a year.

Note

Referenced by

Product Delivery Playbook: Planning, Estimating and Maintaining Software as It Grows

These are my notes on why software teams keep missing deadlines, keep losing track of what their own product does, and keep ending up with a hundred features and almost no test cases. I wrote them for myself first, after watching the same failure repeat sprint after sprint and re

Note