Product delivery glossary
The terms that come up in every delivery conversation, defined the way I actually use them rather than the way a certification course does. Where a definition has a tool or a longer article attached, it is linked.
Jump to a term
- Acceptance criteria
- The specific, testable conditions a piece of work must satisfy to be considered complete. Good criteria are written before development starts and are specific enough that QA can test against them without asking a follow-up question.
- Common failure: criteria written as a restatement of the title. "The user can log in" is a title. "A user with a valid email and password is redirected to the dashboard; an invalid password shows an inline error without clearing the email field" is acceptance criteria.
- Related articles: Product Requirements Clarity Checklist That Ships · How to Write Acceptance Criteria Teams Can Ship
- Backlog
- The ordered list of work a team has committed to shaping and delivering. Note the two words doing the work: ordered, and committed to. A list of everything anyone has ever requested is an intake queue, not a backlog.
- Related article: How to Prioritize Product Backlog Without Chaos
- Capacity
- The amount of work a team can actually take on in a sprint, after ceremonies, absence and the focus factor have been deducted from raw available hours. Distinct from availability, which is the number before those deductions and the number most teams accidentally plan against.
- Tool: sprint capacity planner.
- Cost of delay
- What it costs the business, per unit of time, to not have a feature yet. Making this explicit is the fastest way to settle a prioritisation argument, because it converts "this is important" into a number that can be compared with another number.
- Related article: Product Backlog Prioritization Framework That Ships
- Cycle time
- How long a work item takes from the moment someone starts it to the moment it is released. More useful than velocity for predicting delivery, because it measures flow rather than batch output, and it exposes queues that velocity hides.
- Daily standup
- A short daily check on progress toward the sprint goal and on anything blocking it. Useful when it ends with a named owner for each blocker; useless when it turns into a status report to a manager.
- Related article: How to Run Delivery Standups That Move Work
- Definition of done
- The checklist every item must clear before it counts as complete: tested, reviewed, documented, deployable, and in regulated products, compliant. It is a team agreement, not a policy handed down, and it only works if the team actually enforces it on itself.
- In licensed markets, pulling regulatory checks into the definition of done is the single highest-leverage process change available.
- Related articles: Definition of Done for Product Teams That Ship · A Product Team Operating Model That Ships
- Definition of ready
- The conditions an item must meet before it can enter a sprint: understood, sized, with acceptance criteria and no unresolved external dependency. Teams that skip this spend the first two days of every sprint discovering what they committed to.
- Related article: A Product Team Operating Model That Ships
- Delivery audit
- A fixed-length review of how a team turns decisions into shipped work: backlog, ceremonies, release process and recent launches. The output is a ranked list of bottlenecks and a plan, not a maturity score.
- Related article: Delivery Audit for Software Teams That Need to Ship
- Epic
- A body of work too large for one sprint, broken into stories that each deliver something on their own. If the stories inside an epic only make sense when all of them ship together, it is not an epic - it is one large item that has been chopped up for reporting purposes.
- Focus factor
- The share of a team's time that reaches sprint work once support, interruptions, context switching and unplanned work are accounted for. An assumption informed by the last few sprints, not a measurement of the next one. A plan that assumes 90% is hoping.
- Fractional Product Owner
- An experienced Product Owner who works with a team for a set number of days a week instead of full time. Fits teams that need the role done properly before they can justify, or find, a full-time hire.
- Related article: When Fractional Product Owner Services Fit
- Kanban
- A delivery method based on continuous flow with explicit limits on work in progress, rather than fixed-length iterations. Better suited than Scrum to teams whose work arrives unpredictably - support, platform and operations teams especially.
- OKR (Objectives and Key Results)
- A goal-setting structure pairing a qualitative objective with two to four measurable key results. Useful for connecting a roadmap to business outcomes; harmful when key results become a list of features to ship, which converts a goal framework into a delivery contract.
- Related article: How to Align Your Product Backlog With OKRs
- Product operations
- The shared tooling, data, rituals and templates that keep product decisions moving across teams. Worth investing in once several teams repeat the same coordination work by hand.
- Related article: When Product Operations Consulting Pays Off
- Product Owner
- The person accountable for the value the team delivers: owning the backlog, setting the order, defining what done means, and being available to decide. The role is defined by decision authority. A Product Owner who has to escalate every trade-off is a business analyst with a different job title.
- Related articles: What Is a Product Owner? Roles and Responsibilities · Product Owner Versus Project Manager Explained
- Product roadmap
- A sequenced view of the outcomes a product is working toward, and roughly when. It is a statement of intent that should change as you learn; a roadmap that never changes is usually not being used.
- Related article: Why Your Product Roadmap Keeps Slipping Again
- Refinement (grooming)
- The continuous activity of breaking down, clarifying and sizing upcoming backlog items so they are ready before planning. Refinement is the cheapest intervention available in most struggling teams, and the first thing dropped when a team feels busy.
- Regression testing
- Verifying that new work has not broken existing behaviour. A fixed cost of every release regardless of what the release contains, which is why it should be budgeted explicitly rather than absorbed into individual tickets.
- Tool: story point estimator includes a regression buffer.
- Release forecast
- A range of likely completion dates based on remaining scope, past throughput and expected scope growth. An honest forecast gives best, likely and worst cases; a single date is a promise, not a forecast.
- Tool: release date forecaster gives all three from your own backlog and velocity.
- Related article: How to Forecast Release Dates Without Guesswork
- Release management
- Planning and controlling how finished work reaches production: release windows, sign-offs, rollback plans and communication. In regulated products it is also where compliance evidence gets collected.
- Related article: Software Release Management Guide for Teams
- RICE
- A prioritisation score: Reach multiplied by Impact multiplied by Confidence, divided by Effort. Its value is not the number but the four separate judgements it forces into the open, particularly confidence, which is where most inflated priorities hide.
- Tool: RICE backlog prioritiser.
- Scope creep
- Work added to a commitment after it was made. Some is healthy - it means you are learning. It becomes fatal when the arrival rate of new scope approaches the team's delivery rate, at which point no amount of effort moves the finish date closer.
- Tool: release date forecaster models this directly.
- Related article: How Scope Creep Breaks Product Delivery
- Scrum
- A delivery framework built on fixed-length sprints, three accountabilities (Product Owner, Scrum Master, developers) and five events. Scrum is a container: it tells you when to have conversations, not how to make good product decisions inside them.
- Spike
- A timeboxed piece of research whose output is knowledge rather than shipped software. The correct response to any item the team cannot size confidently, and a far cheaper way to resolve uncertainty than committing to a date and discovering the problem mid-sprint.
- Story point
- A relative unit of size combining effort, risk, repetition and complexity. Points are compared with each other, never converted to hours at the item level - the moment a team agrees "three points is one day", points become hours with extra ceremony.
- Tool: story point estimator.
- Related articles: Estimation: Story Points, Forecasting, Optimism · Story Points Without the Estimation Theater
- Velocity
- The number of story points a team completes per sprint, averaged over recent sprints. A planning input, not a performance metric. The moment velocity is reported upward as a measure of productivity, it inflates, and the team loses its only forecasting instrument.
- Tool: release date forecaster uses velocity and its variability.
- Related article: Story Points Without the Estimation Theater
Disagree with one of these? Good - most of them are contested, and the definitions a team actually operates by matter more than the ones in a textbook. Tell me which one and why.
Something isn't shipping. Let's find out why.
Send me three sentences about what's stuck, or take the free 30-minute call. Either way you'll get an honest read - including if the answer is that you don't need me.