About The Agile Dictionary
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.
d is for...
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.
Also: Task Complete Definition, Punch List
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 work space.
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.
Also: Iteration Review, Sprint Review
A meeting, held at the end of an iteration, at which the development team demonstrates working software and solicits feedback from the product owner, the customer, management, other development teams and other project stakeholders. In Scrum, this meeting is called a Sprint Review.
Mike Cohn describes the format of a Sprint Review in his introduction to Scrum:
“The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.”
In Scrum, the meeting is time boxed to no more than 5% of development time, i.e., one hour at the end of a one-week sprint.