This table defines agile terms as used in Full Scale agile™ (FuSca™). Many are in line with definitions in other systems or general business, however, and will be useful to people new to agility.
| Acceptance Criteria | A short, measurable statement by which the team can prove to the Customer or Team Guide the team achieved what it was supposed to in a user story or epic. |
| Action Item | A statement of something to be done as a result of a decision, covering the task, who chose to do it, and the report date they chose. |
| Actual Hours | The number of labor hours a team member has spent on a task since the start of a sprint. |
| Agile | A philosophy of work management that emphasizes minimal pre-planning; rapid, iterative development of complete deliverables in small chunks; and self-organizing teams. |
| Agile Liaison | A representative of a non-Agile organization who provides requirements for and input into a FuSca program’s planning relevant to that organization. |
| Agile Release Manager | The facilitator and coach for release planning and execution, equivalent to a Facilitator (“Scrum Master” in other systems) but at the cross-team level. |
| Architect | A subject-matter expert who provides requirements for and input into FuSca planning related to their discipline, such as a system architect or technical lead. |
| Backlog | The collection of user stories from which the team pulls stories to work on in Kanban or when planning a sprint. See “Epic Backlog,” “Product Backlog,” or “Release Backlog.” |
| Base Capacity | The maximum number of labor hours available to any team member in a given sprint, allowing for team-wide reductions like holidays or company meetings. |
| Blocker | Any technical issue, task delay, dependency or other problem that may prevent a story from getting committed to a sprint, or from being completed in a sprint after commitment. |
| Burndown Chart | A bar or line chart showing how many labor hours are left to do on incomplete tasks in the sprint, and possibly how many stories have been accepted. |
| Business Requirement | A deliverable needed by your organization to market, sell or support your product or service. |
| Capacity | The number of labor hours each team member can commit to sprint work in the next sprint. |
| Card | A note card on which a user story is written in a paper tracker, or a graphic version in a digital tracker. |
| Ceremony | One of the formal team meetings held by a Scrum team as part of a sprint: Planning, Daily Standup (“scrum”), Demonstration, and Retrospective. |
| Change Agent | Someone actively helping to drive an Agile transformation effort (compare to next two entries). |
| Change Leader | The person who starts and guides an Agile transformation effort. |
| Change Sponsor | A manager who provides the justification, drive, and resources to see an Agile transformation through to completion. |
| Clock Time | The total time a task or process takes to complete (“labor hours” plus “run time”). |
| Collocated Team | A team whose members are geographically close enough to meet together physically each day. |
| Customer | Preferably an external customer who interacts with the team regularly, usually a representative of a purchasing company; in more typical settings, an internal representative of the external customers. |
| Customer Requirement | See “User Requirement.” |
| Daily Standup | A meeting of 15 minutes or less in which team members commit to tasks for the next labor day and report on whether they did those tasks, also called a “scrum.” |
| Definition of Done | A team agreement specifying what assumptions can be made about a deliverable when a stakeholder hears the related story has been accepted. |
| Demonstration Ceremony | The meeting at the end of a sprint in which the team shows what it accomplished to the Customer and stakeholders and gets input for future work. |
| Dependency | An action outside of a story or epic that must be completed before that story or epic can be completed. |
| Epic | A requirement that takes more than one sprint to complete, which gets broken into a set of user stories. |
| Epic Backlog | The list of user stories required to complete an epic and not yet scheduled into a sprint. |
| Estimated Hours | The number of labor hours the team member who volunteered for a task believes will be required to complete the task as of the start of the sprint (compare to “To-do Hours”). |
| External Dependency | A dependency on an action from another organization, team, or individual contributor (see “Dependency”). |
| Facilitator | The Scrum team member who serves part-time as the meeting facilitator and process coach (called the “Scrum Master” in other systems). |
| Fibonacci Sequence | A set of numbers starting with 1 in which each subsequent number is created by adding the two previous numbers, thus: 1, 2, 3, 5, 8, 13, 21, and so on. Used for estimating user story sizes by some Scrum teams. |
| Gold-plating | Adding functionality or features not required to meet the Acceptance Criteria, possibly wasting time if customers do not like the addition. |
| Grooming | The activity in which the team develops a thorough understanding of each story, which may be done as regular or irregular meetings or during an expanded Planning Ceremony; also done for epics during Release Planning. |
| Hybrid Agile | Any of a number of suboptimal schemes that attempt to bridge the gap between agile and waterfall practices rather than shifting the entire organization to an Agile mindset. |
| Ideal Burndown | The line on a burndown chart showing how many labor hours must be completed each day to complete all estimated hours by the end of the sprint; for releases, the unit of measure is user stories. |
| Internal Dependency | A dependency on another action within the team’s control (see “Dependency”). |
| Iteration | Generally, an incremental improvement to a product or service, but also sometimes used as a synonym for a “Sprint.” |
| Kanban | An Agile method which brings into development and then releases stories continuously, while limiting the number of stories in progress, so the team doesn’t multitask much or become overwhelmed. |
| Labor Hour | An hour spent working on a specific task, or in meetings related to it (compare to “Run Time” and “Clock Time”). |
| Lessons-Learned | See “Retrospective Ceremony.” |
| Observer | A meeting attendee without the right to speak in a given ceremony unless asked to. |
| Parent | A type of story that links two or more child stories for tracking together below the epic level. |
| Participant | A meeting attendee with the right to speak without being asked in a given ceremony. |
| Planning Ceremony | A formal meeting at the start of each sprint in which team members meet to determine what stories they will commit to completing in the sprint, and to finish the planning of those stories. |
| Planning Release | A period composed of multiple sprints in which a set of epics is completed. |
| Point | See “Story Point.” |
| Potentially Releasable Product | The general goal of any sprint: The next version of a team’s deliverables, which could be released to customers from a functional standpoint, but might not be for business reasons. |
| Product Backlog | The collection of all stories the team thinks will need to be delivered at some point but not yet assigned to a release or sprint in Scrum, or in progress under Kanban. |
| Product Owner | See “Team Guide.” |
| Project | Per the Project Management Institute, “a temporary endeavor undertaken to create a unique product, service, or result.”[1] |
| Project Sponsor | The person providing the organizational budget or otherwise considered to have primary responsibility for the success of a project. |
| Program | The work and the people doing it to complete a major initiative, product, or service, usually requiring multiple projects. |
| Rank Order | The means of prioritizing in Agile, by listing user stories or epics from highest to lowest business value and technical chronology in the backlog. |
| Release | See “Planning Release” or “Version Release.” |
| Release Backlog | The collection of all epics in a release, and stories the team thinks will need to complete them within a Planning Release but not yet assigned to a sprint. |
| Release Manager | See “Agile Release Manager.” |
| Release Velocity | The minimum number of epics the program gets accepted in most Planning Releases. |
| Retrospective Ceremony | The last meeting of each sprint, in which the team reviews the sprint to identify what went right, what went wrong, and what to improve. |
| Risk | An event that could prevent a story from getting completed within a sprint or an epic within a release, or a bad effect that could be caused by completing the story/epic. |
| Run Time | The time a process runs on its own without human intervention (compare to “Labor Hour” and “Clock Time”). |
| Scrum (meeting) | See “Daily Standup”; in this site, referred to with a lower-case “s” (“scrum”) to differentiate it from the Scrum method. |
| Scrum (method) | An Agile method that plans work within short periods of time using a standard set of meetings (see “Ceremony”). |
| Scrum Master | See “Facilitator.” |
| Self-Organizing | A type of team that does not have a single leader directing the structure and work of the team, also known as “self-directing” or “self-managing.” |
| Shared Story | A user story copied between two Scrum teams to specify which tasks each will do for it, used to address a dependency (see “Dependency”). |
| Simplicity | Per the Agile Manifesto, “the art of maximizing the amount of work not done.” |
| SMART Goal | An objective written to be specific, measurable, action-based, realistic, and time-bound. |
| SME | See “subject-matter expert.” |
| Solutioning | Discussing how a story or epic will be completed, beyond the minimum necessary to create or estimate tasks for it. |
| Spike | A research or root-cause analysis story; these typically require less grooming because, by definition, less is known about them and only decisions are delivered. |
| Splitting | Creating a copy of an incomplete story and, if applicable, directing the original tasks to one or the other copy. |
| Sprint Backlog | See “Sprint Plan.” |
| Sprint Cycle | The standard length of a team’s sprints, from one to four weeks. |
| Sprint Goal | In FuSca, the number of stories the team aims to pull into a sprint during planning, usually equal to the team’s velocity (see “Velocity”). |
| Sprint Plan | The collection of stories the team promises to deliver by the end of the sprint, also called a “Sprint Backlog.” |
| Stakeholder | Anyone with a job-related interest in the team’s efforts. |
| Standard Labor Rate | An hourly figure computed from the organization’s total salary and cost of benefits, possibly adding other costs like equipment and electric bills, divided by the labor hours in a year and averaged across all workers. |
| Story | See “User Story.” |
| Story Point | A subjective rating of the size of one story relative to another, based on its amount of work, complexity, and level of risk; not part of FuSca. |
| Subject-Matter Expert | The person in the organization with the most experience and information about a technology, skill set, knowledge base, etc., needed by the team to complete its deliverables (“SME”). |
| Task | A step required to complete a story. |
| Team | A small group, at least three and preferably no more than eight people, with a mix of skill sets and interdependent roles but a common responsibility or purpose. |
| Team Guide | The team member with primary responsibility for converting requirements into user stories and maintaining rank order of those stories (called the “Product Owner” in other systems). |
| Team Manager | A supervisor who evaluates the performance of any of the team members, impacts individuals’ pay, and/or hires and fires members. |
| Technical Requirement | Work that will not be obvious to the users but must be done to enable their requirements, usually affecting multiple stories/epics. |
| To-Do Hours | The number of labor hours the team member who volunteered for a task believes will be required to complete the task after work on it has begun (compare to “Estimated Hours”). |
| Tracker | A paper or software tool for creating, scheduling, and relaying progress on stories and their tasks. |
| User | In the three-part user story statement, usually an end user of your product or service if at all possible, but sometimes someone inside the company needing a deliverable from the team. |
| User Requirement | What the end users want a product or service to do and why, also called a “Customer Requirement.” |
| User Story | A user, technical or business requirement presented in a standard format and small enough to complete in one sprint. |
| Version Release | A set of deliverables requiring more than one Planning Release to complete. |
| Velocity | The minimum number of stories the team gets accepted most sprints. |
| Waterfall | The traditional or “predictive” form of project management which plans all of the work before starting the work, finishes the development before doing the major testing, etc. |
[1] Project Management Institute 2013.