Agile Glossary and Terminology: Agile Methodology is an umbrella term for several iterative and incremental software development methodologies. This Agile glossary is meant to represent an overview of Scrum-related terms. Some of the mentioned terms are not mandatory in Scrum, but have been added because they are commonly used in Scrum.To learn more about the Scrum framework, to identify which of these terms are required elements of Scrum and to understand how the mentioned elements are connected, refer the Scrum Guide™ and the Scrum Glossary.
Acceptance Test Driven Development (ATDD)
Test-first software development practice in which acceptance criteria for new functionality are created as automated tests. The failing tests are constructed to pass as development proceeds and acceptance criteria are met.
Acceptance Criteria
Those criteria by which a work item (user story) can be judged to have been successfully implemented and tested. A story is ‘done’ when all criteria pass testing; conversely, a story is not ‘done’ if any criteria fail testing. Acceptance Criteria are discreet testable features that relate to the Conditions of Satisfaction that describe a higher level of conditions that, when met, deliver business value.
Acceptance Testing
An acceptance test is a formal description of the behaviour of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios. In many cases, the aim is that it should be possible to automate the execution of such tests by a software tool, either ad-hoc to the development team or off the shelf.
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.
Agile Development
Agile development is a conceptual framework and approach to software development based on principles in the Agile Manifesto. The term is an “umbrella” for a number of specific methodologies based on iterative development techniques where requirements and deliverables evolve through collaboration between self-organizing, cross-functional teams.The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Systems Development (DSDM), Lean Development, and Feature Driven Development (FDD).
Agile Manifesto
A Manifesto for Agile Software Development is an historical document authored in February of 2001 at a ski resort in Utah. The meeting was held to discuss different approaches to lightweight, responsive, adaptable software development. The Manifesto represents their combined best thinking. It comprises two parts: four value statements and twelve principles. Here are the four value statements of the Manifesto:”We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.”
Agile Methods
Some well-known agile software development methods include:
Agile Modeling
Agile Modeling is a practice-based methodology for Modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for Modeling software that can be applied on a software development project in a more flexible manner than traditional Modeling methods.
Antipattern
Antipatterns are common solutions to common problems where the solution is ineffective and may result in undesired consequences
Application Lifecycle Management (ALM)
Also called ALM, Application Lifecycle Management is the management platform of the entire software application lifecycle, from planning to the final release. Key components of the platform include the ability to handle change management, workflow, source code management, task management, testing and bug tracking, reporting and analytics.
Automated Build
In the context of software development, build refers to the process that converts files and other assets under the developers’ responsibility into a software product in its final or consumable form. The build is automated when these steps are repeatable, require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository.
Backlog
A backlog is an ordered list of items representing everything that may be needed to deliver a specific outcome. There are different types of backlogs depending on the type of item they contain and the approach being used
Backlog Grooming
Backlog grooming is when the product owner and some, or all, of the rest of the team refine the backlog on a regular basis to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.
Behavior Driven Development (BDD)
BDD is a practice where members of the team discuss the expected behavior of a system in order to build a shared understanding of expected functionality.
Branching
Branching is the duplication of objects under revision control (such as a source code file, or a directory tree) in such a way that the newly created objects initially have the same content as the original, but can evolve independently of the original. Branching can take two forms, static or dynamic. In static branches, copy and label operations are used to duplicate a given branch. The duplicate then can evolve independently. With dynamic branches, usually implemented in streams, only the label operation is used, to flag the point in time that a stream diverged from its parent stream. Both branching forms support some form of merging, so that code changes made on a branch can be re-integrated into another branch, as is typical in parallel development processes.
Burn-down Chart
A chart which shows the amount of work which is thought to remain in a backlog. Time is shown on the horizontal axis and work remaining on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing work remaining may be expected to fall. The amount of work may be assessed in any of several ways such as user story points or task hours. Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart
Burn-up Chart
A chart which shows the amount of work which has been completed. Time is shown on the horizontal axis and work completed on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing the work done may be expected to rise. The amount of work may be assessed in any of several ways such as user story points or task hours. The amount of work considered to be in-scope may also be plotted as a line; the burn-up can be expected to approach this line as work is completed.
Business Agility
Business agility is the ability of an organization to sense changes internally or externally and respond accordingly in order to deliver value to its customers.
Coherent/Coherence
The quality of the relationship between certain Product Backlog items which may make them worthy of consideration as a whole.
Collective Ownership
Collective code ownership is the explicit convention that every team member can make changes to any code file as necessary: either to complete a development task, to repair a defect, or to improve the code’s overall structure.
Continuous Deployment
Continuous deployment aims to reduce the time elapsed between writing a line of code and making that code available to users in production. To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.
Continuous Integration
Continuous Integration is the practice of merging code changes into a shared repository several times a day in order to release a product version at any moment. This requires an integration procedure which is reproducible and automated.
CRC Cards
Class Responsibility Collaborator (CRC) Cards are an object oriented design technique teams can use to discuss what a class should know and do and what other classes it interacts with.
Cross-functional Team
Team comprised of members with all functional skills and specialties necessary to complete a project from start to finish.
Customer Development
Customer development is a four-step framework that provides a way to use a scientific approach to validate assumptions about your product and business.
Daily Meeting
Daily time-boxed event of 15 minutes, or less, for the Development Team to re-plan the next day of development work during a Sprint. Updates are reflected in the Sprint Backlog.
Definition of Done
The definition of done is an agreed upon list of the activities deemed necessary to get a product increment, usually represented by a user story, to a done state by the end of a sprint.
Definition of Ready
Definition of Ready involves creating clear criteria that a user story must meet before being accepted into an upcoming iteration. This is typically based on the INVEST matrix.
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.
DMAIC
The five stages of a cycle of continuous improvement associated with the “six sigma” approach.
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.
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
An epic is a large user story.
Estimation
In software development, an “estimate” is the evaluation of the effort necessary to carry out a given development task; this is most often expressed in terms of duration.
Exploratory Testing
Exploratory testing is, more than strictly speaking a “practice,” a style or approach to testing software which is often contrasted to “scripted testing.”
Extreme Programming
Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.
Facilitation
A facilitator is a person who chooses or is given the explicit role of conducting a meeting.
Feature-Driven Development (FDD)
Feature Driven Development (FDD) is an Agile method for developing software based on an iterative and incremental software development process. The main purpose of FDD is to deliver tangible, working software repeatedly in a timely manner.
Forecast (of functionality)
The selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.
Four D’s
The four types of tasks that can make up an Agile story.
Frequent Releases
An Agile team frequently releases its product into the hands of end users, listening to feedback, whether critical or appreciative.
Given When Then
The Given-When-Then formula is a template intended to guide the writing of acceptance tests for a User Story: (Given) some context, (When) some action is carried out, (Then) a particular set of observable consequences should obtain.
Heartbeat Retrospective
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
Increment
A piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole – form a product.
Incremental Development
In an Agile context, Incremental Development is when each successive version of a product is usable, and each builds upon the previous version by adding user-visible functionality.
Information Radiators
“Information radiator” is the term for any of a number of visual displays which a team places in a highly visible location, so that all team members can see the latest information at a glance.
Inspect and Adapt
An Agile concept where teams evaluate a project by looking at the product, listening to each other’s feedback and ultimately improving the process or changing course.
Integration
“Integration” (or “integrating”) refers to any efforts still required for a project team to deliver a product suitable for release as a functional whole.
INVEST
The acronym INVEST stands for a set of criteria used to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it.
Iron Triangle
A concept of project management to visualize a situation where all three project constraints of cost, scope, and time are fixed at the start of the project. As the project progresses, no one constraint may change without a change in at least one of the remaining two.
Iteration
An iteration is a timebox during which development takes place. The duration may vary from project to project and is usually fixed.
Iterative Development
Agile projects are iterative insofar as they intentionally allow for “repeating” software development activities, and for potentially “revisiting” the same work products (the phrase “planned rework” is sometimes used; refactoring is a good example).
Kanban
The Kanban Method is a means to design, manage and improve flow for knowledge work and allows teams to start where they are to drive evolutionary change.
Kanban Board
A Kanban Board is a visual workflow tool consisting of multiple columns. Each column represents a different stage in the workflow process.
Lead Time
Lead Time is the time between a customer order and delivery. In software development, it can also be the time between a requirement made and its fulfillment.
Milestone Retrospective
A Milestone Retrospective is a team’s detailed analysis of the project’s significant events after a set period of time or at the project’s end.
Minimum Marketable Feature (MMF)
A Minimum Marketable Feature is a small, self-contained feature that can be developed quickly and that delivers significant value to the user.
Minimum Viable Product (MVP)
A Minimum Viable Product is the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Mob Programming
Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.
Mock Objects
Mock Objects (commonly used in the context of crafting automated unit tests) consist of instantiating a test-specific version of a software component.
Niko-niko Calendar
A Niko-niko Calendar is updated daily with each team member’s mood for that day. Over time the calendar reveals patterns of change in the moods of the team, or of individual members.
Pair Programming
Pair programming consists of two programmers sharing a single workstation (one screen, keyboard and mouse among the pair).
PDCA
The four stages of a cycle of continuous improvement popularized by W. Edward Deming.
Personas
Personas are synthetic biographies of fictitious users of the future product.
Planning Poker
An approach to estimation used by Agile teams. Each team member “plays” a card bearing a numerical value corresponding to a point estimation for a user story.
Points (estimates in)
Agile teams generally prefer to express estimates in units other than the time-honored “man-hours.” Possibly the most widespread unit is “story points.”
Product Backlog
An ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner.
Product Backlog refinement
The activity in a Sprint through which the Product Owner and the Development Teams add granularity to the Product Backlog.
Product Owner
The role in Scrum accountable for maximizing the value of a product, primarily by incrementally managing and expressing business and functional expectations for a product to the Development Team(s).
Project Chartering
A high-level summary of the project’s key success factors displayed on one wall of the team room as a flipchart-sized sheet of paper.
Quick Design Session
When “simple design” choices have far-reaching consequences, two or more developers meet for a quick design session at a whiteboard.
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.
Refactoring
Refactoring consists of improving the internal structure of an existing program’s source code, while preserving its external behavior.
Relative Estimation
Relative estimation consists of estimating tasks or user stories by comparison or by grouping of items of equivalent difficulty.
Role-feature-reason
The “role-feature-reason” template is one of the most commonly recommended aids to write user stories: As a … I want … So that …
Rule of Simplicity
Rules of Simplicity is a set of criteria, in priority order, proposed by Kent Beck to judge whether some source code is “simple enough.”
Sashimi
An Agile concept of delivering value in slices rather than in layers/stages. An Agile Story is sashimi because it can be proven it is done. It is not possible to prove that a requirements document is done.
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
The role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum.
Scrum of Scrums
A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10.
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.
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.
Sign Up for Tasks
Members of an Agile development team normally choose which tasks to work on, rather than being assigned work by a manager.
Spike
Timeboxed investigation of feasibility via a basic implementation experiment or prototype to test out new, unknown, risky or complex technical solutions. The result of a Spike is to inform future implementation decisions.
Sprint
Time-boxed event of 30 days, or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps.
Simple Design
A team adopting the “simple design” practice bases its software design strategy on a set of “simple design” principles.
Sprint Backlog
An overview of the development work to realize a Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality. Managed by the Development Team.
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
Time-boxed event of 8 hours, or less, to start a Sprint. It serves for the Scrum Team to inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint backlog.
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
Time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period.
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.
Scrum of Scrums
A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10.
Sign Up for Tasks
Members of an Agile development team normally choose which tasks to work on, rather than being assigned work by a manager.
Simple Design
A team adopting the “simple design” practice bases its software design strategy on a set of “simple design” principles.
Story Mapping
Story mapping consists of ordering user stories along two independent dimensions.
Story Splitting
Splitting consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.
Sustainable Pace
The team aims for a work pace that they would be able to sustain indefinitely.
Task Board
The most basic form of a task board is divided into three columns labeled “To Do,” “In Progress,” and “Done.” Cards are placed in the columns to reflect the current status of that task.
Test Driven Development (TDD)
“Test-driven development” is a style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests) and design (in the form of refactoring).
Team
A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis.
Team Room
The team (ideally the whole team, including the product owner or domain expert) has the use of a dedicated space for the duration of the project, set apart from other groups’ activities.
Three C’s
“Card, Conversation, Confirmation” is a formula that captures the components of a User Story.
Three Amigos
Three amigos refers to the primary perspectives to examine an increment of work before, during, and after development. Those perspectives are Business, Development, and Testing.
Three Questions
The daily meeting is structured around some variant of the following three questions: What have you completed? What will you do next? What is getting in your way?
Timebox
A timebox is a previously agreed period of time during which a person or a team works steadily towards completion of some goal.
Ubiquitous Language
Striving to use the vocabulary of a given business domain, not only in discussions about the requirements for a software product, but in discussions of design as well and all the way into “the product’s source code itself.”
Unit Testing
A unit test is a short program fragment written and maintained by the developers on the product team, which exercises some narrow part of the product’s source code and checks the results.
Usability Testing
Usability testing is an empirical, exploratory technique to answer questions such as “how would an end user respond to our software under realistic conditions?”
User Stories
In consultation with the customer or product owner, the team divides up the work to be done into functional increments called “user stories.”
Values
When the values of Commitment, Courage, Focus, Openness and Respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and builds trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.
Velocity
An optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.
Version Control
Version control is not strictly an Agile “practice” insofar as it is now widespread in the industry as a whole. But it is mentioned here for several reasons.
XP (Extreme Programming)
“Extreme Programming,” one implementation of the Agile methodology that focuses on producing the simplest coding situation for application requirements and includes practices such as pair programming, incremental design and continuous integration.
Disclaimer: All the content related to Scrum Guide is taken from scrumguides.org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.
A well-maintained product backlog is crucial for successful product development. It serves as a single…
Incremental value to the customer refers to the gradual delivery of small, functional parts of…
A Product Market refers to the group of potential customers who might be interested in…
The Professional Agile Leadership - Evidence-Based Management (PAL-EBM) certification offered by Scrum.org is designed for…
The Professional Agile Leadership (PAL I) certification, offered by Scrum.org, is designed to equip leaders…
Choosing the right Scrum Master Certification depends on your current experience and career goals. If…