Glossary of Agile Scrum Terms


  • Acceptance Criteria: The conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.

  • Activity: A Scrum practice that involves taking action or performing a process.

  • Agile (software development): A set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

  • Agile Manifesto: Also called the Manifesto for Agile Software Development, is a formal proclamation of four key values and 12 principles to guide an iterative and people-centric approach to software development.

  • Artifact: A tangible by-product produced during product development. There are 3 artifacts in Scrum: The Product Backlog, the Sprint Backlog and the Increment.


  • Backlog Grooming (aka Product Backlog Grooming or Product Backlog Refinement): An activity of keeping the backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.

  • Backlog Grooming Session: aka Backlog Refinement Session. The team (or part of the team including the product owner) meet regularly to "groom the product backlog", in a formal or informal meeting which can lead to any of the following: removing user stories that no longer appear relevant. creating new user stories in response to newly discovered needs.

  • Burndown Chart: The trend of work remaining across time in a Sprint, a release or in a product. The burndown chart is a publicly displayed chart showing remaining work in the Sprint backlog. Updated every day, it gives a simple view of the Sprint progress.

  • Burnup Chart: A burn up chart, or burnup chart, tracks progress towards a projects completion. In the simplest form of burn up chart there are two lines on the chart: A total work line (the project scope line) and A work completed line


  • Capacity: The quantity of resources available to perform useful work. A concept used to help establish a WIP limit by ensuring that we only start work to match the available capacity to complete work.

  • Ceremony: A ritualistic or symbolic activity that is performed on well-defined occasions. Some people refer to the core Scrum activities of sprint planning, daily scrum, sprint review, and sprint retrospective as ceremonies.

  • Chicken: Someone who is interested in the project but does not have formal Scrum responsibilities and project accountabilities.

  • Continous delivery: Deploying each new feature to users immediately after it is built, integrated, and tested.

  • Cross-functional team: A team composed of members with all the functional skills (such as UI designers, developers, testers) and specialties necessary to complete work that requires more than a single discipline.


  • Daily Scrum Meeting: A short (fifteen-minute) status meeting held daily by each team. Team members synchronize their work and progress and report any impediments to the ScrumMaster for removal.

  • Done: A checklist of the types of work that the team is expected to successfully complete by the end of the sprint, before it can declare its work to be potentially shippable. A bare-minimum definition of done should yield a complete slice of product functionality, one that has been designed, built, integrated, tested, and documented and will deliver validated customer value.

  • Done-done: A term often used by teams to mean the work performed during the sprint is “really” done. Done to the point where the customer would think the work is done (potentially deliverable). Teams that use "done-done" often use the term done to mean “we did as much work as we were prepared to do!” Well-functioning agile teams don’t need two concepts (done and done-done).


  • Epic: A large user story, perhaps a few too many months in size, that can span an entire release or multiple releases. Epics are useful as placeholders for large requirements. Epics are progressively refined into a set of smaller user stories at the appropriate time. (Related terms: Theme, Story, Task)

  • Estimated Work Remaining: The number of hours that a team member estimates that remains to be worked on for any task. This estimate is updated at the end of every day the Sprint Backlog task is worked on.

  • Estimation: The process of agreeing on a size measurement for the stories in a product backlog usually using the Planning Poker.


  • Feature: A coherent business function or attribute of a software product or system. Features are large and chunky and usually comprise many detailed (unit) requirements. A single feature typically is implemented through many stories. Features may be functional or non-functional; they provide the basis for organizing stories.

  • Fibonacci Sequence: The sequence of numbers where the next number is derived by adding together the previous two (1,2,3,5,8,13,20…) ; the sequence has the quality of each interval getting larger as the numbers increase; the sequence is often used for Story Points, simply because estimates are always less accurate when dealing with epics.

  • Forecast: The selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.

  • Framework: see Scrum Framework.


  • Increment: Product functionality that is developed by the team during each Sprint. The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.

  • Impediment: Anything that prevents the team from meeting their potential. If it's organization, scrum master is responsible for eliminating it. Otherwise, the team should try to fix it within themselves.

  • Impediment Backlog: A visible list of impediments in a priority order according to how seriously they are blocking the team from productivity.

  • Inspection: One of the three pillars of empirical process control, involving thoughtful examination and processing of feedback to make adaptation decisions regarding the process or product.

  • Integration: The combining of the various components or assets of some or all of a product to form a coherent, larger-scope work product that can be validated to function correctly as a whole.

  • Iteration: A self-contained development cycle focused on performing all of the work necessary to produce a valuable outcome.

  • Iteration and Incremental Process: A style of development that leverages both iterative development and incremental development.


  • Learning Loop: A feedback loop focused on increasing learning. Generally follows these steps: make an assumption (or set a goal), build something (perform some activities), get feedback on what was built, and then use that feedback to inspect what was done relative to what was assumed.


  • Minimum Viable Product (MVP): A product which has just enough features to gather validated learning about the product and its continued development. An MVP is all about getting a product into the hands of your customers quickly and learning from their feedback.


  • Nice-to-have features: Features that are targeted for the upcoming release, but could be excluded if there are insufficient resources to finalize their development.


  • Pig: Scrum slang. Someone occupying one of the three Scum roles (Team, Product Owner, ScrumMaster) who has made a commitment and has the authority to fulfill it. Hence the quote, "The Chicken is involved, but the Pig is committed!"

  • Planning Poker: A game used to apply estimates to stories. It uses the Delphi method of arriving a consensus.

  • Product Backlog: A prioritized list of stories that are waiting to be worked on.

  • Product Backlog Item: Any item that is in the backlog list, which will include user stories, epics and possibly technical stories.

  • Product Backlog Item Effort: Some Scrum practitioners estimate the effort of product backlog items in ideal engineering days. Alternative units might include story points, function points, or "t-shirt sizes" (1 for small, 2 for medium, etc.). The advantage of vaguer units is they're explicit about the distinction that product backlog item effort estimates are not estimates of duration.

  • Product Backlog Grooming : See Backlog Grooming.

  • Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.

  • Product Planning: aka. Envisioning. An activity that captures the essence of a potential product and creates a rough plan for the creation of that product. Envisioning begins with the creation of a vision, followed by the creation of a high-level product backlog and frequently a product roadmap.

  • Product Roadmap: A description of the incremental nature of how a product will be built and delivered over time, along with the important factors that drive each individual release. Useful when developing a product that will have more than one release.

  • Product Vision: A brief statement of the desired future state that would be achieved by developing and deploying a product. A good vision should be simple to state and provide a coherent direction to the people who are asked to realize it.

  • Progressive Refinement: The activity in a Sprint through which the Product Owner and the Development Team add granularity to the Product Backlog.


  • Ready: A checklist of conditions that must be true before a product backlog item is considered ready to pull into a sprint during sprint planning.

  • Refactoring: A technique for restructuring an existing body of code by improving/simplifying its internal structure (design) without changing its external behavior. Refactoring is one of the principal techniques for managing technical debt.

  • Release: A combination of features that when packaged together make for a coherent deliverable to customers or users. Also, a version of a product that is promoted for use or deployment.

  • Release Burndown Chart: A visible chart to show progress toward a release.

  • Release Goal: A clear statement of the purpose and desired outcome of a release. A release goal is created by considering many factors, including the target customers, high-level architectural issues, and significant marketplace events.

  • Release Plan: The output of release planning. On a fixed-date release, the release plan will specify the range of features available on the fixed future date. A plan that communicates, to the level of accuracy that is reasonably possible, when the release will be available, what features will be in the release, and how much will it cost.

  • Release Planning: A collaborative effort involving these roles: Scrum master – Facilitates the meeting. Product owner – Represents a general view of the product backlog. Delivery team or agile team – Provide insights into technical feasibility and dependencies.

  • Retrospective: A session where the Team and Scrum Master reflect on the process and make commitments to improve.

  • Roles: See Scrum Roles.


  • Scrum: An iterative and incremental agile software development framework for managing product development. There are 3 elements of Scrum: Roles, Ceremonies, Artifacts.

  • Scrum Board: aka Task Board or Scrum Task Board. A physical board to visualize information for and by the Scrum Team, often used to manage Sprint Backlog. Scrum boards are an optional implementation within Scrum to make information visible.

  • Scrum Ceremonies: There are 3 types of ceremonies or meetings: Sprint Planning Meeting, Daily Scrum Meeting, and Sprint Review and Retrospection Meeting.

  • Scrum Events: Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

  • Scrum Framework: A collection of values, principles, practices, and rules that form the foundation of Scrum-based development.

  • Scrum of Scrums (SoS): An approach to coordinating the work of multiple Scrum teams wherein one or more members of each Scrum team come together to discuss and resolve inter-team dependency issues.

  • Scrum Master: The ScrumMaster oversees the project, but doesn't manage the team. Instead, the ScrumMaster is a sort of cushion between the client and the team. The ScrumMaster is responsible for setting the rules of the project, but not the delivery of the project.

  • Scrum Roles: There are 3 roles: Product Owner, Scrum Master and the Team.

  • Scrum Team: A self-organizing team consisting of a Product Owner, Development Team and Scrum Master.

  • Self-organization: The management principle that teams autonomously organize their work. Self-organization happens within boundaries and against given goals. Teams choose how best to accomplish their work, rather than being directed by others outside the team.

  • Sprint: A time-box of typically 30 sequential calendar days (or sometimes defined by the team as two to four weeks) during which a team works to turn the Product Backlog it has selected into an increment of potentially shippable product functionality.

  • Sprint Backlog: A list of tasks to be completed during the Sprint.

  • Sprint Backlog Task: One of the tasks that the team or a team member defines as required to turn committed Product Backlog items into system functionality.

  • Sprint Demo: An activity of a sprint review where the completed (done) product backlog items are demonstrated with the goal of promoting an information-rich discussion between the Scrum team and other sprint review participants.

  • Sprint Goal: aka Sprint Theme, the key focus of the work for a single sprint.

  • Sprint Planning Meeting: A one day meeting time-boxed to 8 hours that initiates every Sprint.

  • Sprint Retrospective Meeting: A meeting time-boxed to 3 hours and facilitated by the Scrum-Master at which the Team discusses the justconcluded Sprint that determines what could be changed that might make the next Sprint more enjoyable or productive.

  • Sprint Review Meeting: A meeting time-boxed to 4 hours at the end of every Sprint at which the team demonstrates to the Product Owner and interested stakeholders what it was able to accomplish during the Sprint.

  • Sprint Task: A single small item of work that helps one particular story reach completion.

  • Stakeholder: Someone with an interest in the outcome of a project, either because he or she has funded it, will use it or will be affected by it.

  • Stand-up Meeting: See Daily Scrum Meeting

  • Story: A backlog item usually using the template form: as a [user] I want [function] so that [business value], cf Product Backlog Item. (Related terms: Theme, Epic, Task)

  • Story Mapping: A technique that takes a user-centric perspective for generating a set of user stories. Each high-level user activity is decomposed into a workflow that can be further decomposed into a set of detailed tasks.

  • Story Point: A unit of measurement applied to the size of a story, cf. Fibonacci Sequence T-shirt sizes, powers of 2, are other ways of assigning Story Points.

  • Story Time: The regular work session where items on the backlog are discussed, refined and estimated and the backlog is trimmed and prioritized.


  • Task: see Sprint Task. (Related terms: Theme, Epic, Story)

  • Task Board: see Scrum Board.

  • Task List: The tasks needed to complete the set of stories committed to a Sprint.

  • Team: A cross-functional group of people that is responsible for managing itself to develop software every Sprint.

  • Technology Stack: A combination of software products and programming languages used to create a web or mobile application.

  • Timeboxed: A period of time that cannot be exceeded and within which an event or meeting occurs. A Daily Scrum meeting is timeboxed to 15 minutes and ends at that time regardless.

  • Theme: A collection of related user stories. A theme provides a convenient way to indicate that a set of stories have something in common, such as being in the same functional area.(Related terms: Epic, Story, Task)


  • User Role: The name for a class of product users. One of the key elements of a user story that defines the recipient of the value delivered by a user story.

  • User Story: A convenient format for expressing the desired business value for many types of product backlog items. User stories are crafted in a way that makes them understandable for both business people and technical people. They are structurally simple and typically expressed in a format such as “As a <user role> I want to achieve <goal> so that I get <benefit>.”


  • Veloctiy: The rate at which a team completes work, usually measured in story points.

  • Voice of the Customer (VOC): A term used in business and Information Technology (through ITIL, for example) to describe the in-depth process of capturing customer's expectations, preferences and aversions.


  • What: A term used to describe the domain of the product owner, as distinct for the the team.

  • WaterScrumFall: A hybrid approach to application lifecycle management that combines waterfall and Scrum development methodologies.

  • Work in Progress (WIP): Work that has entered the development process but is not yet finished and available to a customer or user. Refers to all assets or work products of a product or service that are currently being worked on or waiting in a queue to be worked on.

Example of Burndown and Burnup charts:

Related posts: The Birth of Agile, The meaning of Scrum, Glossary of Project Management Terms

#AgileScrum #Glossary

Featured Posts
Recent Posts
Search By Tags
No tags yet.
Let's Connect!
  • White Facebook Icon
  • White Twitter Icon
  • White LinkedIn Icon
  • White Instagram Icon
  • White Pinterest Icon
  • White YouTube Icon

© 2017 mia t lee.  All rights reserved.