Pass/fail tests used to define whether or not a feature is functional, usually developed in parallel to the defining of a feature. These tests may be written in plain English by the customer or product owner (“The user clicks , the session is reset, and the user is redirected to the homepage.”) Ideally, an acceptance test is subsequently automated by the developer so that it can easily run on all iterations of the software, ensuring that the accepted feature has not been broken by newer development. The use of acceptance tests in subsequent iterations is also known as regression testing. Acceptance testing is a key feature of test-driven development (TDD).
In scrum: scrum does not specify testing methods, and testing is not a part of the scrum framework. This said, most scrum teams test, and within the scrum framework, the product owner would be the appropriate person to define acceptance tests.
The concept of acceptance testing exists in other engineering disciplines than software development, and is usually referred to as black-box testing.
Although acceptance testing is common across many Agile disciplines, the term derives from XP. According to C2.com, acceptance tests were first referred to as functional tests, because they test whether or not a feature works. Kent Beck, a primary mover behind TDD, proposed the change in terminology in April 2000.
An umbrella term for iterative, incremental software development methodologies. Agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean, and Feature-Driven Development (FDD). Agile methodologies arose in opposition to the traditional, phase-driven “Waterfall” development method, which emphasizes top-down project management, “big design up front,” silos for architecture and design, coding, and testing, and extensive documentation. Agile methodologies share an emphasis on small teams delivering small increments of working software with great frequency while working in close collaboration with the customer and adapting to changing requirements.
The term “Agile” was first used by a group of Software pundits who gathered at a ski lodge in Snowbird, Utah for the express purpose of naming and defining the greater movement in which they deemed themselves to all be participants. The original invitation to Snowbird went out to those interested in “lightweight” development frameworks. The attendees agreed that they didn’t like the negative connotations of that term, and agreed to adopt the term “Agile.”
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.
Backlog refinement is the process of adding new user stories to the backlog, re-sequencing existing stories as needed, creating estimates of effort for previously un-estimated stories, and decomposing large stories into smaller stories or tasks.
Backlog refinement is both an ongoing process as well as more specifically the event or ceremony that occurs regularly within a team’s iteration cycle to accomplish the above.
Scrum trainer and consultant Roman Pilcher explains the significance of backlog refinement to the agile development process: “Grooming the product backlog collaboratively creates a dialogue within the scrum team and between the team and the stakeholders. It removes the divide between “the business” and “the techies.” It eliminates wasteful handoffs, and avoids miscommunication and misalignment. Requirements are no longer handed off to the team; the team members co-author them. This increases the clarity of the requirements, leverages the scrum team’s collective knowledge and creativity, and creates buy-in and joint ownership.”
Scrum Alliance founder Ken Schwaber recommends that teams allocate 5% of their time to revisiting and tending to the backlog.
Background Of The Term
This was originally called “backlog grooming” but was changed in 2013 due to the current negative connotation of “grooming”.
The ceremony is also known as “backlog maintenance” and “story time“.
Plots units of work that remain to accomplish (Y axis) against units of time (X axis). In Scrum, the Burn Down Chart is a key artifact.
Release Burn Down
The units of work that appear on a Burn Down Chart are derived from the Release Backlog. During the process of Backlog Grooming they have been assigned an estimated point value. The trend line on a Release Burn Down Chart will generally trend downward, however, if new items are added to the Release Backlog, then the total points remaining may go up.
The Release Burn Down Chart is the primary tool a team has for visualizing their velocity, the average number of points they accomplish during an iteration.
Iteration Burn Down
The initial point value of work remaining in a Sprint Burn Down chart derives from the work the team commits to accomplish during the Sprint. Work remaining is generally graphed daily. The number of points the team undertakes is based on their established team velocity, i.e., the number of points they routinely complete. In Scrum, no new work may be added once a sprint has begun, so the trend line will never rise. In Extreme Programming, work may be added during a sprint, so the trend line may rise.
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.
The term derives from the philosophy of mathematics, and systems science, where it is used to describe a form of analysis used to identify the functional parts of a system. Decomposition is also a common to software architecture parlance.
A Team’s universally agreed-upon criteria for what makes a unit of work “potentially shippable.” This checklist of steps that must be completed for each unit of work (e.g., task or user story) may include items like “documentation created,” “code review completed,” “all tests created and passing,” etc. The Definition of Done usually takes the form of an information radiator, being posted prominently in the team’s workspace.
A well-crafted Definition of Done may prevent the accumulation of technical debt that naturally arises when team members define “done” loosely and colloquially.
In Extreme Programming, the Definition of Done may be referred to as Task Complete Definition, a Punch List, or a Binary Milestone.
Welcome to iteration zero of The Agile Dictionary! Our goal with this project is to provide broad, authoritative definitions of common Agile terms. You will note that each definition also includes a section titled “etymology,” where we capture the origins of the term wherever possible.
Visit the definitions by clicking on the letters in the navigation bar, or you can search for a term, above.