One80 Services Glossary of Agile Terminology

Acceptance Criteria: These are specific criteria identified by the customer for each functional requirement. The acceptance criteria are written in simple terms and from a perspective of the customer.

Acceptance Test: Acceptance testing is a validation activity conducted to determine whether or not a system satisfies its acceptance criteria. It is the last phase of the software testing process.

Agile Project Management: Agile project management is an iterative approach to planning and guiding project processes. Each iteration is reviewed and critiqued by the project team, which may include representatives of the client business as well as employees. Insights gained from the critique of an iteration are used to determine what the next step should be in the project.

Agile Software Development: Agile software development is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development (ASD) focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as they’re ready.

Agile Manifesto: The Agile Manifesto is a formal proclamation of four key values and 12 principles to guide an iterative and people-centric approach to software development.

Application Lifecycle Management (ALM): Application lifecycle management (ALM) is the supervision of a software application from its initial planning through retirement. It also refers to how changes to an application are documented and tracked.

Backlog: An ever-evolving list of product requirements, prioritized by the customer (or customer representative), that conveys to an Agile team which features to implement first. Agile projects typically employ a top level backlog, known as a product backlog or release backlog, and each Agile team working on a project typically creates a backlog for each development iteration, known as an iteration backlog or sprint backlog.

At either the release level or iteration level, a backlog typically comprises features or requirements, often expressed in terms of user stories, that may be assigned estimates (e.g., in points or hours) by the development team. The customer or customer representative prioritizes the items in the backlog (and may assign them business value).

Backlog Grooming: The process of adding new user stories to the backlog, re-prioritizing existing stories as needed, creating estimates for previously un-estimated stories, and decomposing large stories into smaller stories or tasks. Backlog grooming is both an ongoing process and the name for a meeting.

Behavior Driven Development: Behavior driven development (or BDD) is an agile software development technique that encourages collaboration between developers, QA and non- technical or business participants in a software project. BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read.

Bottleneck: A bottleneck is a sort of congestion in a system that occurs when workload arrives at a given point more quickly than that point can handle it.

Bugs: A software bug is a problem causing a program to crash or produce invalid output. It is caused by insufficient or erroneous logic and can be an error, mistake, defect or fault.

Burn-down Chart: A chart showing the evolution of remaining effort against time. Burn-down charts are an optional implementation within Scrum to make progress transparent.

Burn-up Chart: A chart showing the evolution of an increase in a measure against time. Burn-up charts are an optional implementation within Scrum to make progress transparent.

Capacity: The measure of how much work can be completed with a given, fixed time frame by estimating the number of available, productive work hours for an each individual on the team. The accurately estimate capacity, it is import to factor in all know variables such as meetings, holidays, vacations, administrative activates, and training.

Command and Control: In management, command and control refers more generally to the maintenance of authority with somewhat more distributed decision making.

Continuous Improvement: Continuous improvement is an ongoing effort to improve products, services or processes. These efforts can seek by “incremental” improvements over time or by “breakthrough” or “innovative” improvements all at once.

Continuous Integration: Continuous integration (CI) is a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The goal is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible.

Cycle Time: The amount of time needed to complete a feature or user story during the development process.

Daily Standup/Scrum:A Daily Standup is a whole team meeting that happens at the same time every day that usually lasts 15 minutes or less. The meeting is designed to allow the entire team to synchronize with each other and to understand the flow and challenges of the development process. Each team member should provide the following information: what did I do yesterday, what am I planning to do today, and what impediments do I currently have?

Decomposition: The process of breaking user stories down into a) smaller, more executable user stories or b) tasks. Likewise, epics may be decomposed into user stories, and tasks may be decomposed into more fine-grained tasks. Decomposition is usually performed during backlog grooming and iteration planning, and is an important precursor to story sizing (estimation). Decomposition may also occur throughout the development process. In the typical product backlog, user stories grown more fine grained as they near implementation, and are larger and less detailed the further down the queue they reside.

Definition of Done: A shared understanding of expectations that software must live up to in order to be releasable into production. Managed by the Development Team.

Demo: (Demonstration) At the end of each iteration the development team performs a demonstration of the functionality that has been completed during the iteration. The demo is a ceremony for the business stakeholder to provide feedback on the product’s development.

Development Team: The role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Increment of product every Sprint.

Emergence: The process of the coming into existence or prominence of new facts or new knowledge of a fact, or knowledge of a fact becoming visible unexpectedly.

Emergenetics: The Emergenetics Profile is designed from a psychometric foundation to give each of us an in-depth knowledge of our unique make-up, and provides an understanding of the person that we are. Adopting Emergenetics as part of your Agile journey capitalizes on your investment in self-organized teams through use of common language and understanding provided by the Emergenetics instrument. Emergenetics is a proven tool for team building, communication, leadership development, conflict resolution and coaching.

Empiricism: Process control type in which only the past is accepted as certain and in which decisions are based on observation, experience and experimentation. Empiricism has three pillars: transparency, inspection and adaptation.

Engineering Standards: A shared set of development and technology standards that a Development Team applies to create releasable Increments of software.

Epic: A very large user story that is eventually broken down into smaller stories.

Estimation: The process of agreeing on a size measurement for the stories, as well as the tasks required to implement those stories, in a product backlog.

Extreme Programming: (XP) A software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent “releases” in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

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.

Feature Creep: Feature creep (sometimes known as requirements creep or scope creep) is a tendency for product or project requirements to increase during development beyond those originally foreseen, leading to features that weren’t originally planned and resulting risk to product quality or schedule. Agile tends to reduce the danger of feature creep.

Fist to Five (Fist of Five): Fist to five, also called fist of five, is a technique used by agile software development teams to poll team members and help achieve consensus. To use the technique, the team facilitator restates an action the group may make and asks the team to show their level of support. Each team member responds by holding up a closed fist or the number of fingers that corresponds to the level of support.

Five Levels of Agile Planning: The five levels of Agile planning are Vision, Roadmap, Release, Iteration (or Sprint), and Daily. The top level (Vision) represents the “big picture” of the overall effort and thus the planning at this level encompasses more strategic product information and fewer details on the product specifics. Working through to the bottom level, more details are included in the produced plans, so that in whole, the five levels of Agile planning represents a holistic understanding of what we are building, why we are undertaking the effort, and how we plan to deliver.

Forecast (of Functionality): The selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.
Increment: a piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole – form a product.

Impediment: In Scrum: Anything that prevents a team member from performing work as efficiently as possible is an impediment.

Information Radiator: A group of artifacts that is used to communicate project status to the team and other stakeholders; information radiators are an important part of maintaining transparency and visibility into the team’s progress.

Inspect & Adapt: “Inspect and Adapt” is a slogan used by the Scrum community to capture the idea of discovering over the course of a project emergent software requirements and ways to improve the overall performance of the team. It neatly captures the both the concept of empirical knowledge acquisition and feedback-loop-driven learning.

INVEST: INVEST is an acronym that defines a simple set of rules used in creating well formed User Stories:

Independent: Stories should not be dependent on other stories.

Negotiable: Too much explicit detail regarding particulars and solutions. Stories should capture the essence of the requirement and should not represent a contract on how to solve it.

Valuable: Stories should clearly illustrate value to the customer.

Estimable: Stories should provide just enough information so they can be estimated. It is not important to know the exact way that a particular problem will be solved, it must be understood enough to provide a high level estimate.

Small: Stories should strive to be granular enough in scope that they may be completed in as little time as possible, from a few weeks to a few days.

Testable: Stories need to be understood well enough so that a test can be defined for it. An effective way to ensure testability is to define user acceptance criteria for all user stories.

Iteration / Sprint: A fixed duration period of time where user stories are chosen to work on. The term Sprint comes from the Scrum methodology and is analogous to the term Iteration. A sprint is defined as a 2-4 week increment of software development activities that delivers working software and the end of the increment. External influences are not allowed to change the requirements of the stories being worked on.

Iterative Development: Iterative development is a way of breaking down the software development of a large application into smaller chunks. In iterative development, feature code is designed, developed and tested in repeated cycles.

Kanban: Kanban, pronounced /ˈkɑnˈbɑn/, is a method for developing products with an emphasis on just-in-time delivery and the optimization of flow of work on the team. It emphasizes that developers pull work from a queue, and the process, from definition of a task to its delivery to the customer, is displayed for participants to see.

Lead Time: The amount of time needed to complete a feature or user story from customer request to delivery (includes wait time).

Lean: Lean software development is a translation of Lean manufacturing and Lean IT principles and practices to the software development domain. Adapted from the Toyota Production System and is a set of techniques and principles for delivering more values with the same or less resources by eliminating waste across organizations and business processes.

Paired Programming: Paired programming is an agile software development technique in which two programmers work together at one workstation. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator). The two programmers switch roles frequently.

Persona: (User Persona) Personas are a description of the typical users of a given software.

Pigs and Chickens: “Pigs and chickens” is an analogy used in the Scrum software development model to define the type of role an attendee can play at a daily scrum meeting. A pig is directly accountable for completion of the task at hand. A chicken is somewhat involved in the task at hand but is not the person whose “bacon is on the line” if the task doesn’t get completed on time.

Planning Board: A planning board is used to track the progress of an agile development project. After iteration planning, stories are written on cards and pinned up in priority order on a planning board located in the development area. Development progress is marked on story cards during the week and reviewed daily.

Planning Poker: Also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of tasks in software development.

Product Backlog: Acts as a repository for requirements targeted for release at some point. These are typically high level requirements with high level estimates provided by the product stakeholders. The requirements are listed on the backlog in priority order and maintained by the product owner.

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

Product Owner: The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.

Progressive Elaboration: An iterative approach where planning occurs in cycles rather that all up front. Projects, which use progressive elaboration, typically do planning, and execution and then repeat the process.

Ready: A shared understanding by the Product Owner and the Development Team regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.

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

Release: A release is a deployable software package that is culmination of several iterations of development. Releases can be made before the end of an iteration.

Release Management: Release management is a software engineering process intended to oversee the development, testing, deployment and support of software releases. The practice of release management combines the general business emphasis of traditional project management with a detailed technical knowledge of the systems development lifecycle (SDLC) and IT Infrastructure Library (ITIL) practices.

Release Plan: A release plan is an evolving flowchart that describes which features will be delivered in upcoming releases. Each story in a release plan has a rough size estimate associated with it.

Requirements Creep: Requirements creep (sometimes known as feature creep or scope creep) is a tendency for product or project requirements to increase during development beyond those originally foreseen, leading to features that weren’t originally planned and resulting risk to product quality or schedule. Agile tends to reduce the danger of feature creep.

Retrospective: A team meeting that happens at the end of every development iteration to review lessons learned and to discuss how the team can be more efficient in the future. It is based on the principles of applying the learning from the previous sprint to the upcoming sprint.

Scope Creep: Scope creep (sometimes known as feature creep or requirements creep) is a tendency for product or project requirements to increase during development beyond those originally foreseen, leading to features that weren’t originally planned and resulting risk to product quality or schedule. Agile tends to reduce the danger of feature creep.

Scrum: A framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated roles, events, artifacts, and rules, as defined in the Scrum GuideTM.

Scrum 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 Guide™: The definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland, co-creators of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.

Scrum Master: A Scrum Master is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master’s role is to protect the team and keep them focused on the tasks at hand. The role has also been referred to as servant-leader to reinforce these dual perspectives.

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

Scrum Values: A set of fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.

Scrumban: Scrumban is a mix between Scrum and Kanban, which supposedly contains the best features of both methods.

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.

Silo: A group of people with one shared functionality, separated into a unit away from other groups. (We often see QA in it’s own silo, for example, rather than placing QA next to a developer and allowing them to collaborate side by sidee. Cross-functionality solves this issue and removes silos.)

Spike: A short, time-boxed piece of research, usually technical, on a single story that is intended to provide just enough information that the team can estimate the size of the story.

Sprint / Iteration: A fixed duration period of time where user stories are chosen to work on. The term Sprint comes from the Scrum methodology and is analogous to the term Iteration. A sprint is defined as a 2-4 week increment of software development activities that delivers working software and the end of the increment. External influences are not allowed to change the requirements of the stories being worked on.

Sprint Backlog: At the beginning of each sprint, the team has sprint planning with an end result being a backlog of work that the team anticipates completing at the end of the sprint. These are the items that the team will deliver against throughout the duration of the sprint.

Sprint Execution: Often also referred to as Sprint Execution, the recurring phase within the project lifecycle in which the Agile team executes against the iteration backlog. The goal of this phase is to complete all iteration commitments by delivering working software within the defined time constraints of the iteration. Typically, the iteration execution phase begins with the iteration kickoff and culminates with the iteration review.

Sprint Goal: A short expression of the purpose of a Sprint, often a business problem that is addressed. Functionality might be adjusted during the Sprint in order to achieve the Sprint Goal.

Sprint Planning: Is a pre-sprint planning session attended by the core agile team. During the meeting the Product Owner describes the highest priority features to the team as described on the product backlog. The team then agrees on the number of features they can accomplish in the sprint and plans out the tasks required to achieve delivery of those features. The planning group works the features into User Stories and assigns Acceptance criteria to each story.

Sprint Retrospective: Time-boxed event of 3 hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint.

Sprint Review: Each Sprint is followed by a Sprint review. During this review the software developed in the previous Sprint is reviewed and if necessary new backlog items are added.

Sprint Zero: Sprint Zero is the time used to plan and set-up the foundation needed before a team can execute their first successful iteration. Sprint Zero deliverables may include: identify stakeholders, build the team, training, create high-level architecture diagrams, and set-up environments.

Stakeholder: a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.

Story: (User Story) A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. A user story is also a placeholder for conversation between the users and the team. The user stories should be written by or for the customers for a software project and are their main instrument to influence the development of the software. User stories could also be written by developers to express non-functional requirements (security, performance, quality, etc.) Read more about user stories here.

Storyboard / Taskboard: A wall chart with cards and sticky notes that represents all the work for in a given sprint. The notes are moved across the board to show progress.

Task: A user story can be broken down in to one or more tasks. Tasks are estimated daily in hours (or story points) remaining by the developer working on them.

Taskboard / Storyboard: A wall chart with cards and sticky notes that represents all the work for in a given sprint. The notes are moved across the board to show progress.

Team: The Team is responsible for delivering the product. A Team is typically made up of 5–9 people with cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.). It is recommended that the Team be self-organizing and self-led, but often work with some form of project or team management.

Test Driven Development: Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.

Timeboxing: Timeboxing is a planning technique common in planning projects (typically for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally two to six weeks long), with each part having its own deliverables, deadline and budget.

User Persona: Personas are a description of the typical users of a given software.

User Story: A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. A user story is also a placeholder for conversation between the users and the team. The user stories should be written by or for the customers for a software project and are their main instrument to influence the development of the software. User stories could also be written by developers to express non-functional requirements (security, performance, quality, etc.)

Velocity: Refers to a number which describes how much work the team can get done over a period of time.

Vertical Slice: Showing off a feature in an application that works from start to finish but may be limited in scope. For example a rope bridge crossing a chasm is immediately useful and allows people to cross. Having that in place can help to build a better bridge later.

Waterfall: The waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.

The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

WIP: Also known as Work in Progress is any work that has been started but has yet to be completed.

WIP Limits: Limiting the Work-in-Progress (WIP) so that the team maintains focus on completing stories\tasks, maintaining quality, and delivering value.

XP: (Extreme Programming) A software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent “releases” in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.