Agile Glossary

Whenever teams feel pressured to finish work ahead of deadlines that may not be realistic, they may lack sufficient time for activities such as code refactoring, and writing and executing various forms of tests. Over time, if teams are repeatably put in a similar situation of feeling they need to cut corners to meet a deadline, it gets increasingly difficult to add new features to, or even maintain, the code base, and the greater the degree of difficulty in enhancing or maintaining the code, the higher the level of technical debt. The use of a familiar financial metaphor helps reinforce the idea that the greater the amount of technical debt that is accrued in any given system, the more difficult it is to support, and eventually only "interest" is being paid on the debt, while nothing is being paid on the "principal."

A style of programming where three activities are tightly coupled: coding, testing (in the form of writing unit tests) and design (in the form of refactoring). It can be described by the following of rules: write a “single” unit test describing an aspect of the program; run the test, which should fail because the program lacks that feature; write “just enough” code, the simplest possible, to make the test pass; refactor the code until it conforms to the simplicity criteria; repeat, adding more unit tests and the corresponding code.

A means of capturing the essential elements behind a user story as originally articulated by Ron Jeffries: a "Card" (often a Post-It note or index card), which serves as a physical and/or virtual token giving durable form to what would otherwise only be an abstraction; a "Conversation" which can take place at different times and places among the members of the team, to get clarity about what is to be built, and which may be supplemented by written documentation, and; the "Confirmation", a means of making sure there is agreement on what "done" means for that user story, typically formalized via one or more Acceptance Criteria.

A constraint that is placed on an event, where when a particular amount of time has expired, the event is officially over. A two-week iteration or Sprint is an example of a timebox. It is also common to "timebox" the duration of particular meetings, where they end after a set amount of time.

The time that a product is actually being worked on, and value is being added, in a Lean Production system (an Agile Development Team that applies Lean principles such as flow and Kanban is part of a Lean Production system). This is typically only a small proportion of the total production time, since much of the time is taken up by moving, queuing, and waiting due to hand-offs. See also wait time.

Four stages of group dynamics - Forming - Storming - Norming - Performing - first described by Bruce Tuckman in 1965, in a Psychological Bulletin article titled "Developmental sequence in small groups." It has been observed that when a group experiences a change to its composition, for instance, when a person leaves or a new person joins, they often regress to one of the earlier stages. It for this reason, among others, that many practitioners prefer to keep groups (teams) intact for a reasonably long period of time.