Glossary
Quick, plain-English definitions of the terms used across this wiki. Where a term has its own article, its entry links straight to it.
Can't find a term?
If a word you heard at work isn’t listed here, it may be a synonym for one that is — try the search box above.
A
AARRR
The “pirate metrics”: five customer-lifecycle metrics (Acquisition, Activation, Retention, Referral, Revenue). See AARRR.
Adaptation
Modifying or adjusting something to fit a need or a change. Don’t confuse with Adoption.
Adoption
The process of people taking up and starting to use a product; cf. “adoption rate,” “friction in adoption.” Distinct from adaptation. See Adoption.
Agile
A family of approaches, defined by the Agile Manifesto, that favors short iterations, working software, and responding to change. A mindset, not a single method. See Agile software development.
Agile Manifesto
The 2001 document (4 values, 12 principles) that defines what “agile” means. See Agile Manifesto.
Acceptance criteria
The specific, testable conditions a single User story must meet to be accepted as done. Per-story; don’t confuse with the team-wide Definition of Done. See Acceptance criteria.
B
Backlog
An ordered list of work not yet done. See Product backlog and sprint backlog.
Backlog refinement
The ongoing work of clarifying, ordering, and estimating upcoming backlog items. Also called “backlog grooming” (older term). See Backlog refinement.
Business case
The argument for why an investment is justified (costs vs. benefits vs. alternatives). Built from a Feasibility study’s findings.
Business Model Canvas
A one-page, nine-box model of a business (Osterwalder), abbreviated BMC. The parent of the Lean canvas, which adapts four of its boxes for startups.
Business plan
A document describing how a venture will be built, run, marketed, and funded, written after deciding to proceed. Don’t confuse with a Feasibility study (which decides whether to proceed).
D
Daily Scrum
The short daily sync in Scrum. Also called “standup,” “daily standup,” “morning sync.” See Daily Scrum.
Definition of Done
The team-wide checklist that makes an increment releasable, abbreviated DoD. Team-wide; contrast with per-story acceptance criteria. See Definition of Done.
DevOps
A culture and set of practices uniting development and operations, built on automation and CI/CD. (planned)
E
Edge case
An unusual or boundary scenario the software must still handle (empty input, maximum values, the first or last item). Cousins: corner case (several edges at once) and boundary case.
Epic
A large body of work too big for one Sprint, broken down into multiple user stories.
Error case
Also called the unhappy path: a scenario where something goes wrong (invalid input, a failure) that the system must handle gracefully. The opposite of the happy path.
Extreme programming
An agile framework centered on engineering practices like pair programming and test-driven development, abbreviated XP. See Extreme programming.
F
Feasibility study
A pre-commitment assessment (technical, economic, legal, operational, schedule: “TELOS”) that ends in a go/no-go recommendation. Don’t confuse with a business plan (how to execute) or a business case (why to invest). See Feasibility study.
Functional requirement
What the system must do (a specific behavior). Contrast with a Non-functional requirement. See Functional requirement.
H
Happy path
The default scenario where the user gives valid input and everything succeeds. Contrast with edge cases and the error case (unhappy path).
I
Increment
The sum of completed work that is potentially releasable at the end of a Sprint. Its commitment is the Definition of Done.
INVEST
Checklist for a good User story: Independent, Negotiable, Valuable, Estimable, Small, Testable.
Iteration
A fixed, repeated development time-box. In Scrum it’s called a Sprint.
K
Kanban
An agile method based on visualizing work, limiting work-in-progress, and continuous flow (no fixed iterations). See Kanban.
L
Lean canvas
A one-page, nine-box business-model template; the lean alternative to a long business plan. Adapted from the Business Model Canvas. See Lean canvas.
M
Mockup
A static, high-fidelity visual of a screen (colors, type, branding), but not interactive. Middle of the fidelity spectrum: Wireframe → Mockup → Prototype. See Mockup.
MVP
Minimum viable product: the smallest real, shippable product that can deliver value and generate learning. Don’t confuse with a Prototype (a throwaway) or a proof of concept.
N
Non-functional requirement
How well the system must perform (quality attributes like speed, security, reliability), abbreviated NFR. Contrast with a Functional requirement. See Non-functional requirement.
P
Product backlog
The single ordered list of everything that might be built. Its commitment is the Product Goal. See Product backlog.
Product Manager
Owns product strategy and the why/what across the whole product; business- and market-facing, abbreviated PM. Not the same as a Product Owner; see Roles and job titles for the full comparison.
Product Owner
The Scrum accountability that owns the backlog and delivered value on one team, abbreviated PO. Distinct from a Product Manager (see Roles and job titles).
Proof of concept
A small build to test whether something is technically feasible, abbreviated PoC. Don’t confuse with a Prototype (tests UX) or an MVP (a real product).
Prototype
An interactive, throwaway simulation used to test flows before building. End of the fidelity spectrum. See Prototype.
S
Scrum
The most widely used agile framework, organized around fixed sprints. See Scrum.
Scrum Master
The Scrum accountability responsible for the team’s effectiveness and process. Sometimes mislabeled “project manager,” “delivery lead,” or “iteration manager.”
Software development life cycle
The stages a product moves through, from idea to retirement, abbreviated SDLC. See Software development life cycle.
Software development process
The overall approach (methodology / process model) used to move through the SDLC. See Software development process.
Software requirements specification
The formal plan-driven document capturing all requirements (functional, non-functional, constraints), abbreviated SRS. Also called a “requirements document”; the agile alternative is a Product backlog of stories. Don’t confuse with a BRD or PRD. See Software requirements specification.
Sprint
A fixed time-box (1–4 weeks) in Scrum during which a usable increment is produced. Generic term: “iteration.” See Sprint.
Sprint backlog
The items selected for the current Sprint plus the plan to build them. Its commitment is the Sprint Goal. Subset of the Product backlog.
Sprint planning
The Scrum event that starts a sprint by selecting and planning the work. See Sprint planning.
Sprint retrospective
The event where the team improves its own process (“retro”). Don’t confuse with a post-mortem or the sprint review. See Sprint retrospective.
Sprint review
The event where the team shows the increment to stakeholders (“demo,” “show and tell,” “sprint demo”). Don’t confuse with the retrospective. See Sprint review.
T
Task
A technical to-do that a User story is broken into. Story = what/why; task = how.
TELOS
The five dimensions of a Feasibility study: Technical, Economic, Legal, Operational, Scheduling.
U
User story
A short, user-centered description of a feature: “As a <role>, I want <goal>, so that <benefit>.” See User story.
Use case
An older, more formal, step-by-step description of a user’s interaction. Heavier than a User story.
V
Verification and validation
Verification (building it right, to spec) vs validation (building the right thing, for the user); the process/quality view of testing, abbreviated V&V. Don’t confuse verification with validation, or QA (preventive process) with QC (defect detection). See Verification and validation.
W
Waterfall model
A sequential process model where each phase completes before the next begins. See Waterfall model.
Wireframe
A low-detail structural sketch of a screen. Start of the fidelity spectrum: Wireframe → Mockup → Prototype. See Wireframe.