What are they talking about? A glossary of Scrum and Agile terminology

What are they talking about? What is the difference between acceptance criteria and the definition of done? Every field has its own special vocabulary and agile software development is no exception.

Artwork courtesy of Laura Quattri. Used by Permission

From acceptance criteria to working agreements, the following guide will help you navigate the waters by understanding the terminology.

• Acceptance criteria – tests which must be passed for the Product Owner or customer to consider the story accepted. The Team should verify these before submitting a story for final approval. Acceptance tests help ensure external quality. Most product backlog items can be mapped to one or more acceptance criteria. See Definition of Done and Quality, external.
• Agile – a movement for finding better ways of developing software. Scrum and Extreme Programming are two leading examples. Others, such as Kanban or Lean Startup do not define themselves in the agile tradition but are based on compatible values and principles.
• Agreement – the basis for planning and completing work in Scrum. Examples: the definition of done, the selected product backlog, the sprint contract, and the definition of ready.
• Artifact – something that archaeologists find when digging. Often used to describe the documents produced by a project management methodology. Scrum artifacts are all living documents to guide and monitor work. In Personal Agility they are called “tools.”
• Backlog Refinement – the process of getting backlog items ready for implementation in the sprint. Typically, this means taking large, poorly defined backlog items, discussing them, and replacing them with several “smaller” backlog items that are individually less complex and easier-to-implement, but still add up to the original whole.
• Best practice – some consultant’s solution to someone else’s problem. Is your context similar enough to the original for the solution to be applicable to you? Questionable. Will you do better by coming up with you own solution? Usually.
• Ceremony – a fancy word for a meeting or routine process. In Scrum and Personal Agility these are called “events” to signify that something important happens and you want and need to be there!
• Chickens – deprecated term for people interested in the results of a project, but not 100% committed to its success (e.g. due to conflicting priorities). Chickens can be very disruptive to the team. Never call someone a chicken. Spectators is a better metaphor. A professional sports game is played for the spectators, but the spectators are not allowed to interfere with the game.
• Commitment – a core value of Scrum which should not be interpreted to mean that the team is expected to burn itself out trying to achieve unrealistic goals sprint after sprint after sprint.
• Daily Scrum – a daily opportunity for the team to inspect and adapt on their progress throughout the sprint. Three traditional questions help the Team recognize that they need to talk to each other (preferably right after the daily scrum).
• Definition of Done – an agreement on what ‘this backlog item is done’ actually means. Helps assure internal and external quality for each story. Often expressed as a checklist to be completed before submitting the story to the Product Owner. The definition of done applies to individual backlog items and to each increment, but not to individual tasks or whether the overall release has enough functionality to be delivered to the customer.
• Development Team – consists of 3 to 9 people who have all the skills necessary to get from “idea” to “done” (not from spec to ready-to-test). Often referred to simply as “the Team.” The Team (and only the Team) creates the solution. It is responsible for “How?”. The Team is protected from noise but not isolated from the organization.
• Done (for a feature) – a binary state. Either a backlog item is completed according to the definition of done, or not.
• Done (for a product) – a judgement call by the Product Owner. At the end of a sprint, if the Product Owner believes that it’s worthwhile to release, the product should be releasable. If it’s not, there is undone work which should be addressed at the level of the definition of done in future sprints.
• Estimate – the team’s best guess at the size, complexity or time involved to convert a PBI into a piece of finished functionality. An estimate is not a commitment. More time on backlog refinement is usually more helpful to performance than more time on estimation.
• Extreme programming (XP) – an agile approach to software development, often applied in conjunction with Scrum. XP defines the engineering practices needed to produce quality software in an iterative environment.
• Evil – something which is difficult or impossible to get rid of but avoiding it is generally good for you. Weeds in the garden is one example. Treating multitasking, bugs, dependencies and spillover as evil is usually good for team performance.
• Forecast – the Team’s best guess at how much finished functionality it can deliver by the end of a sprint. The Team is normally expected to respect all the terms of the sprint contract, i.e. quality, time and cost, which are more important than scope.
• How-to-demo – a short workflow for demonstrating to the Product Owner that the functionality has been implemented correctly. Also, useful to limit scope creep while implementing a product backlog item (“story”).
• Impediment – anything which slows the Team down or prevents someone from working. Although the Scrum Master is charged with removing impediments and all Scrum events provide regular opportunities to recognize them, impediments can be identified and eliminated at any time by anyone.
• Increment – an additional slice of customer visible value delivered at least once per sprint. The latest increment must integrate with the previous delivered increments to form a working whole.
• Multitasking – pretending you can do more than one thing concurrently. In theory, if there is unused capacity available, multitasking can improve performance. However, multitasking has a cost, and if there is no free capacity it lowers performance by introducing wait times and creating dependencies between otherwise independent processes. Usually focusing on getting one thing done at a time is better for performance.
• Must – absolutely required, or else! The Product Owner must attend sprint planning 1, otherwise the meeting cannot be held.
• PBI – Product Backlog Item.
• Pigs – deprecated term for those people 100% committed to the project at hand. Always refers to Scrum Master and Development Team. If it does not also refer to the Product Owner, this is a sign of dysfunction. While it might be okay to call yourself a pig, “players on the field in a professional sports match” is a better metaphor. Yes, the game is played for the spectators, and the spectators can have a surprising influence on the result, but the players must be able to play without undue interference. See also Chickens.
• Priority, sequence – which item comes first, second, third, etc. The term priority is deprecated in Scrum because a) it contains emotional overtones and b) two items could have the same priority but in Scrum they must have a unique place in line, that is, in the product backlog.
• Product Backlog – the single source of requirements for the product under development. It consists of functional and non-functional requirements. It is not used to plan work or define intermediate artifacts, like a specification, which have no value for the customer or user.
• Product Backlog Item (PBI) – an entry in the product backlog consisting of a description (often a user story), a sequence position, and an estimate. Often enriched with acceptance criteria and other useful information. A PBI is not a specification, but rather a reminder to hold a conversation shortly before implementation.
• Product Owner – a servant leader who guides the Development Team to produce customer visible value. Sometimes called the voice of the customer (or user) or the organization’s ambassador into the Scrum Team, the role represents all interests outside the Development Team to the team.
• Quality, external – Did you build the right thing? Does it perform the way the customer or user wants and expects? Acceptance tests strive to ensure external quality.
• Quality, internal – Did you build it right? Does the product behave the way its creators intended? Unit tests ensure that a program continues to behave correctly, even after modifications have been made.
• Quality, overall – Are there enough features present to justify delivery? Also known as ‘fitness for use.’ A state achieved incrementally in Scrum. The Product Owner decides when this has occurred by calling for a release.
• Release burn-down chart – a tool for visualizing the progress of the team toward a medium-term release goal. The x-axis represents time, measured in sprints. The y-axis is the sum of the estimates in the product backlog. When a PBI is done, its estimate can be deducted from the burn-down chart. It is the primary tool for ensuring that wishes and probable reality stay reasonably aligned.
• Release burn-up chart – serves the same purpose as a release burn-down chart with a different visual representation. The y-axis represents the cumulative sum of the estimates of the features that have been included in the product increment.  When a feature is completed, it’s estimate is added to the burn-up chart.
• Release Planning Meeting – the Scrum Team comes together to refine the product backlog to focus on creating a release. Although time-boxed, there is no decision to be taken at the end of the meeting, so it is often a useful preparation for sprint planning. This term is deprecated, replaced by backlog refinement, which leaves more space for creative thinking.
• Retrospective – the Development Team (and anybody they invite) reflects on how they worked to identify improvements for the next sprint. Usually the Scrum Master is invited to facilitate.
• Ritual – fancy word for a meeting or routine process. Kind of implies that you won’t miss anything if you don’t go. Call it an event or an activity instead.
• Scrum – a simple, team-based approach to solving complex problems. A mindset based on a culture of transparency and regular cycles of inspection and adaption. A popular approach for developing software.
• Scrum Master – a servant leader who helps Product Owner and Development Team perform better. Helps the rest of the organization recognize which interactions with the Scrum Team are helpful and which are not. Encourages doing more of what’s helpful and less of what isn’t. Coaches and facilitates. Removes impediments. Sometimes called a change agent, the Team’s ambassador to the organization, or voice of common sense.
• Scrum Team – all three roles together make up the Scrum Team. Sometimes called the whole team.
• Selected Product Backlog – deprecated term for the subset of (by definition top priority) product backlog items that the Team reasonably believes it can complete during the sprint (often mistakenly called the sprint backlog). Today this is called the forecast.
• Sequence – a unique ordering. First, second, third… The product backlog is sequenced.
• Should – highly recommended. The Scrum Master should be present at the daily scrum. This is much stronger than optional. However, no activity in Scrum is cancelled due to the absence of the Scrum Master. See also Must.
• Spillover – work that has been started but not completed by the end of the sprint. Contrary to popular belief, spillover does not automatically carry over into the next sprint. Excessive spillover is typically a symptom of over-commitment in sprint planning and/or multitasking in the team. Technical debt is a subtle form of spillover.
• Sprint – a time-boxed period for completing work. A sprint consists of planning, doing and review, both of the results and of how the team worked. Maximum time-box is 30 days. 2 weeks is common. All forecast work should be done by the end of the sprint.
• Sprint Backlog – the selected product backlog, enriched with a technical concept and a task planning. The Sprint backlog represents the team’s concept for achieving the goal set during the first half of sprint planning. The plan is updated daily by the Team.
• Sprint Contract – the agreement between Product Owner and Team at the beginning of a sprint: time (sprint duration), cost (team composition), quality (definition of done) and scope (selected product backlog). If the team should fail to deliver on any aspect, it should fail on scope.
• Sprint Planning – addresses two questions: what and how. The meeting is divided in two halves, sometimes referred to as sprint planning 1 and sprint planning 2 for addressing these questions. While the Scrum Guide considers this to be one activity, many practitioners consider each half to be a separate event with its own time-box.
• Sprint Planning 1 (SP1) – the Product Owner and the Development Team agree on what will be developed during this sprint. The Product Owner defines priorities, the Team estimates how much is doable. Both parties influence the final agreement: the forecast and the sprint goal.
• Sprint Planning 2 (SP2) – the Development Team decides how to solve the problem accepted in SP1. The result is a technical concept and a task planning, often in the form of a task board.
• Sprint Review – the Scrum Team meets with users and stakeholders to inspect and adapt the product, based on done functionality. They will review what has and has not been completed and reflect on how to change the product backlog before the next sprint planning. This event is for getting feedback about the product from the stakeholders, not for evaluating the team’s performance or whether individual backlog items are done.
• Stoos – a movement for finding better ways of managing organizations, named for the gathering that took place in Stoos, Switzerland in 2012. Inspired by the agile movement, Stoos seeks to catalyze a lasting change in how businesses do business.
• Story – term often used to refer to a product backlog item, even if not formulated as a user story. Can also refer to a medium sized backlog item (on the scale of epic >> story >> grain of sand).
• Story Point (SP) – a widely used, though not universally used unit to gauge the size of a PBI relative to other PBIs, estimate the size of a project and monitor progress. Something like a kilometer for code, so you can use the math of distance, rate and time to monitor progress and estimate completion.
• Task – the Team uses tasks to plan the work in the sprint. When all tasks associated with a story are completed, the story should be done. Typically, a task represents a goal for the day, or something smaller. Most coaches no longer recommend estimating tasks in hours.
• Task Board – a visual representation of the work to be completed in the sprint. Typically, 4 columns, organized in swim lanes, per story: story, tasks waiting, tasks in progress, tasks done. Often supplemented with burn-down charts, impediments and other useful information. The task board belongs to the Development Team, not the Scrum Master, Product Owner or outside managers.
• TDD Test Driven Development – also known as red-green-refactor. 1) write a failing unit test (red) 2) code a first draft to turn the test green, keeping all other tests green) 3) “refactor” to create an improved and final draft. TDD improves productivity by reducing misunderstood requirements, rework, and escaped errors.
• Team – an older term for the Development Team. Because effective collaboration between Product Owner and Development Team is associated with high performance, Product Owner, Scrum Master and Development Team are now referred to as the “Scrum Team”.
• Technical debt – a consequence of poor engineering practices which make a program difficult to modify. Like financial debt, technical debt must be paid off or technical bankruptcy follows: throw the program away and write a new one.
• Time-box – a constraint to prevent a complex situation from degenerating into chaos. All events in Scrum are time-boxed.
• Undone work – can you release the product at the end of the sprint? If not, there is undone work. Typical examples include regression testing, usability testing, customer acceptance tests. The less undone work you have, the more predictable your release dates. See Spillover.
• Unit tests – automated tests written by the Development Team to assure internal quality. Unit tests enable refactoring and provide an essential safety net, so that changes and fixes do not introduce new errors.
• User story – a people-centered approach to defining requirements with a standardized form: as <some role or persona> i want <some value> so that I can achieve <some goal or purpose>. The word ‘user’ should never appear in a user story.
• Velocity – a unit to gauge the speed of development and estimate the completion date of large projects. Usually expressed as story points per sprint.
• WAP – widely adopted practice, often used together with Scrum, but not part of Scrum—you may do it or not if you feel it applies to you. Examples include story points, user stories, definition of ready.
• Whole team – an XP term for the Scrum Team.
• Work in progress, WIP – work that has started but has not yet been completed. Lots of WIP is associated with poor performance and inability to get things done. See Spillover.
• Working agreement – an agreement among interested parties to enable more effective work. Working agreements are the basis for improvement in Scrum.