Caution: These definitions relate to how these terms are used within this guide, but your customer may use different terms. Start by speaking their language and do not try to persuade them to use these terms. If, over time, you find ways to use the concepts described here to streamline processes it may be appropriate to carefully propose alternative terms where it adds value to do so.
An ordered list of backlog items. The backlog order defines the order of delivery and is decided by the product owner. Compare to the epic roadmap.
A small, individually-deliverable and valuable outcome — that is, a statement of a desired result that will be achieved once the backlog item is delivered. For example, user story, bug or tech task. This contrasts with the broader term "Product backlog item" used by Scrum and reflects the deliberate distinction made in this guide between epics, which are placeholders for larger deliverables, and the small items which they are broken down into.
A description of some user-visible behaviour that is not working as intended. Two different causes can give rise to bugs: either the software does not do what was specified, or it does what was specified but that specification was wrong or incomplete. It is best to take a pragmatic approach and treat anything which a normal user would say is not working properly as a bug, regardless of the cause. Of course, if the cause is actually a significant missing piece of functionality then that is different and it is better to treat it as a new feature request — that is, an epic or story.
Used to describe both the technique and tools for automating build, testing and deployment of software. See CI/CD for more information. CI/CD usually stands for Continuous Integration and Continuous Delivery, but sometimes "Deployment" is substituted for "Delivery" to indicate that as well as producing potentially deployable production-ready software, it is also automatically deployed to production.
The average time from when a backlog item is taken from the next-up backlog to when it is done. It is sometimes useful to track several different measures for different definitions of done, such as "ready to deploy" or "deployed" to focus in on different areas of the workflow. See also lead time.
An individually-deliverable and valuable outcome — that is, a statement of a desired result that will be achieved once the epic is delivered. Each epic must be split into several backlog items for implementation. Epics should represent things that are visible and valuable, but they do not always need to represent functionality that is directly visible to end-users. For example, "Basic, self-serve MI reports" or "Cross-browser testing capability" would be perfectly valid epics that would bring visible benefit to different sets of internal users.
An ordered list of epics with an indication of when each is expected to be delivered. The roadmap order defines the order of delivery and is decided by the product owner. See Planning.
Used to refer to how the work to deliver a feature is split. A horizontal slice is the part of a feature within one technology or architecture "layer". For example, front end, back end or database. It is not recommended to split delivery into horizontal slices. Compare to vertical slice.
A fixed time period (default two weeks, or possibly one week for short engagements) during which backlog items are taken through the delivery workflow. Toward the end of each iteration, a retrospective and iteration review are held.
The average time from when a backlog item is added to the next-up backlog to when it is done. See also cycle time.
A vehicle (physical or not) for delivery of value. In particular, a service can also be a product.
A single person who is empowered and responsible for deciding the order of the epic roadmap and backlog, and is ultimately responsible for determining if the implementation of a backlog item meets the definition of done.
Often shortened to "retro". A meeting held at the end of each iteration which includes the whole team and inspects how things went during the iteration. The focus is on celebrating and reinforcing what went well, identifying problems that were encountered and deciding on actions to drive improvement. Further reading: scrum.org.
Also known as "walking skeleton". A minimal path through a user journey or similar, usually a simple "happy path", implemented first to provide a foundation for the remainder of delivery. The focus is on reducing risk by providing early learning about integration points and other areas of possible complexity and uncertainly. The aim is to establish all the mechanisms needed for onward iteration, including automated tests, CI/CD and observability. Other benefits are that it provides the fastest path toward getting actionable feedback from users and releasing a simple version early to unlock business benefits.
Often shortened to "tech task". A backlog item that does not affect user-visible behaviour. These should still be framed as outcomes to achieve rather than things to do so that the focus stays on delivering value and solutionising is done just in time. For example, "Improve visibility of test failures" would be better than "Slack alert on test failures", but a workable compromise can be to include both for clarity, such as "Improve visibility of test failures e.g. with slack alert on shared channel".
User Acceptance Testing. Validation by a user representative (usually the product owner or a subject matter expert) that the implementation of a user story meets the user needs or that a bug has been properly fixed.
A backlog item that affects a vertical slice of user-visible behaviour.
Used to refer to how the work to deliver a feature is split. A vertical slice is a small but fully-functioning part of the feature, implemented through all technology or architecture "layers", for example, front end, back end and database. It is recommended to split delivery into vertical slices. Compare to horizontal slice.