The process of breaking user stories down into smaller user stories and tasks.

See Story Splitting which is now much more commonly used.

Background Of The Term

The term derives from the philosophy of mathematics and from systems science where it is used to describe a form of analysis used to identify the functional parts of a system. Decomposition is also common to software architecture parlance.

Posted in d | Leave a comment

Definition of Done

Also: Task Complete Definition, Punch List

A Team’s universally agreed-upon criteria for what makes a unit of work “potentially shippable.” This is a checklist of steps that complete each unit of work (e.g., task or user story). It 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 Agile Learning Labs’ Blog post “How To Create The Definition Of Done” there is detail about the steps to creating a Definition of Done and how to keep the team on track.

Background of term

In Extreme Programming, the Definition of Done is called Task Complete Definition, a Punch List, or a Binary Milestone.

Further Learning

Agile Learning Labs blog post – Definition of Done

Posted in d | 1 Comment


Also: Sprint Review, Iteration Review

Previously, this dictionary entry for Demo was a main one, and the entries for Sprint Review and Iteration Review pointed to here.

However, because of the current common use of the scrum framework and its terminology we have decided to make this entry a stub and to point to Sprint Review instead.

Posted in d | 2 Comments


Referring to the development of software systems, DevOps has been broadly defined as “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality”[1].

DevOps includes practices such as continuous integration, continuous automated testing, and automated deployment to ensure speed, quality, stability, and reliability.

DevOps is a cultural shift within many organizations. The historical separation between software development and IT operations is removed by having all participants contribute to the entire software development lifecycle. They are aligned around shared goals of fast delivery, high quality, and customer expectations.

Background of the term:

DevOps is a portmanteau of the two words development and operations that refer to software development and IT operations.

Further Learning:

What is DevOps?

[1] DevOps: A Software Architect’s Perspective, 1st ed. by Bass, Weber, and Zhu.

Posted in d | Leave a comment


See Definition of Done.

Posted in d | Leave a comment


A large user story that awaits decomposition into smaller stories prior to implementation. When an epic story works its way up the backlog, it is usually so decomposed. Epics are sometimes far off on the development horizon and have lower priority.

In the scrum framework stories that are sprint ready must be small enough that they can be confidently implemented within the timebox of a single sprint.

NB: One can easily be tempted to associate the term ‘epic’ with importance; in Agile, epic relates only to size.

Background of the Term

As it relates to agile methodologies, Mike Cohn coined the term epic in his book User Stories Applied: For Agile Software Development. Chapter 2 of that book is available here as a pdf, in which there is discussion of epics.

Further Learning:

Agile Alliance | Glossary | Epic

Don’t Finish Your Epics! Deliver More Value Instead.

User Stories Applied: For Agile Software Development

Posted in e | 8 Comments

Evolutionary Development

See Iterative Development.

Posted in e | Leave a comment

Extreme Programming (XP)

An Agile software development methodology that emphasizes customer involvement, transparency, testing, and frequent delivery of working software.

The Extreme Programming canon includes a Customer Bill of Rights and a Developer Bill of Rights. Its core values are communication, simplicity, feedback, courage, and respect. XP is a developer-centric methodology. Unlike scrum, it prescribes specific coding practices like pair programming in which two developers work side by side at a single machine, automated unit testing, and frequent integration. Another key practice in XP is refactoring, or the continual internally-visible improvement of design and code.

The basic advantage of XP is that the whole process is visible and accountable. The developers make concrete commitments about what they will accomplish, show concrete progress in the form of deployable software, and when a milestone is reached they will describe exactly what they did and how and why that differed from the plan. This allows business-oriented people to make their own business commitments with confidence, to take advantage of opportunities as they arise, and to eliminate dead-ends quickly and cheaply. — Kent Beck

Background of the term

In 1996, Chrysler’s visionary CIO, Sue Unger, gave Kent Beck free rein to form a team to tackle the Chrysler Comprehensive Compensation payroll project. During this project Beck along with Ron Jeffries, Ward Cunningham, and Martin Fowler promoted and further developed the practices of what Beck called extreme programming.

Further Learning:

Agile Alliance | Glossary | Extreme Programming (XP)

Extreme programming

Extreme Programming for Beginners made Easy – Roles & Practices

Extreme Programming Explained: Embrace Change, 2nd edition. Kent Beck & Cynthia Andres.

Posted in e | Leave a comment

Feature Team

A feature team is a team that can work across multiple parts of technology stack in order to get features done without depending on other teams.

A common scenario would be a website that has back-end code that runs on the server and front-end code that runs in the web browser. The back-end might be coded in Java and the front-end might be coded in HTML and Javascript. A feature team would include people with Java skills as well as people with HTML and Javascript skills. This allows the team to complete a customer-facing feature which requires changes to both the front-end and back-end of the system.

Feature teams are often contrasted with component teams.

Posted in f | Leave a comment

Functional Test

See Acceptance Test.

Posted in f | Leave a comment