Glossary
Product delivery, defined
The terms that come up in every scoping conversation, defined without hedging - what each one is for, what makes one useful, and where teams usually get it wrong.
A/B Testing
An A/B test shows two versions of something to different groups of real users at the same time and measures which performs better against a metric you chose in advance. The point is to replace an argument about what users will do with a measurement of what they did.
Acceptance Criteria
Acceptance criteria are the specific, checkable things that have to be true before a piece of work counts as finished. You write them before the work starts and agree them between whoever asked for it and whoever builds it. They are what "done" means for that one story.
Agile
Agile is a way of running software work in short cycles, shipping something usable at the end of each one, and changing the plan as you learn. It is a set of priorities rather than a process: working software over documents, responding to change over sticking to a plan.
AI Ethics in Product Work
AI ethics in product work is the practical business of deciding who is accountable for an AI system's output, what data it is allowed to see, and what happens when it is wrong. It is a set of design decisions, not a values statement, and each one has a right answer you can write down.
Backlog Grooming
Backlog grooming, also called backlog refinement, is the ongoing job of keeping your backlog in order: properly scoped, correctly prioritised, and cleared of things that no longer matter. Done well, the top of the backlog is ready to pick up without a conversation first.
Burn Rate
Burn rate is how fast a project is spending its budget - usually money or hours per week. On its own it tells you very little. Compared against how much of the work is actually finished, it is the earliest honest warning you get.
Business Requirements Document (BRD)
A business requirements document (BRD) says what the business needs from a piece of work and why, in money-and-outcomes terms rather than technical ones. On client work it is usually the document the contract points at, which makes it what you open when someone disputes what was included.
Change Order
A change order is a written, agreed change to a project's scope, price or schedule. It turns a casual request into a decision both sides signed off on, which is what stops it turning into an argument later.
Definition of Done (DoD)
A definition of done is the standard every piece of work has to meet before it counts as finished - tested, reviewed, documented, deployed, whatever your team agreed. It applies to every story, unlike acceptance criteria, which belong to one story each.
Entity Relationship Diagram (ERD)
An entity relationship diagram (ERD) is a picture of the things a system stores and how they relate to each other - customers, orders, invoices, and which ones belong to which. It is the shape of your data, drawn so a room can argue about it before it is built.
MoSCoW Prioritisation
MoSCoW sorts requirements into four buckets - Must have, Should have, Could have, and Won't have this time - so the difference between essential and nice-to-have is written down. The fourth bucket is what makes it useful: it records what you deliberately left out.
Product Requirements Document (PRD)
A product requirements document (PRD) says what a feature has to do, who it is for, and how you will know it worked. You write it before the work starts so design and engineering are solving the same problem. It covers the problem and the outcome, not how to build it.
Product Signal
A product signal is evidence about what users actually did, as distinct from a view about what they will do. The useful question in a planning meeting is not whether a claim sounds right, but what kind of signal is behind it - and most claims turn out to have none.
Risk Mitigation
Risk mitigation is the work of reducing either the likelihood of something going wrong or the damage if it does. It starts with naming the risk, which sounds obvious and is the step most projects skip.
Scope Creep
Scope creep is when a project quietly grows without the budget, timeline or price growing with it. It is rarely one decision. It is a pile of small additions, each one reasonable on the day, none of them written down as a change.
Software Architecture
Software architecture is the set of high-level structural decisions about a system - how it is split up, how the parts talk to each other, where data lives, what it runs on. What makes a decision architectural is not that it is technical but that it is expensive to reverse later.
Software Development Life Cycle (SDLC)
The software development life cycle (SDLC) is the set of stages a piece of software passes through from first idea to running system and eventual retirement. It describes what has to happen, not the order or the ceremony - Agile and Waterfall are two different ways of sequencing the same stages.
Sprint Planning
Sprint planning is the meeting at the start of a sprint where the team agrees what it will deliver and how. It works when the backlog was already refined. When it was not, planning turns into a scoping workshop and whatever the team commits to is a guess.
Story Points
Story points measure how much effort a piece of work will take relative to other work - how complicated it is, how much is unknown, and how much of it there is. They are not hours. You compare them to each other, which is what lets a team estimate consistently even though everyone works at a different pace.
Technical Specification
A technical specification describes how something will be built - the architecture, the data model, the interfaces, and why those choices over the alternatives. A PRD says what has to be true. A technical spec says how you are going to make it true.
User Story
A user story describes a piece of work from the point of view of the person who wants it, usually written as "as a [role], I want [thing], so that [benefit]". The point is to keep the reason attached to the work, so whoever builds it can make the small decisions in favour of the right thing.
Waterfall
Waterfall runs a project as a sequence of phases that each finish before the next begins: requirements, then design, then build, then test, then release. Its defining assumption is that you can know the requirements well enough up front to plan the whole thing.
Stop writing this stuff from memory
Spectr turns your meetings into structured specs, requirement documents, and review-ready user stories - with a human approving everything.
Free plan available. 30-day free trial on Starter.