Glossary

Agile is commonly understood as a set of tools, techniques, practices enabiling Agility.

The foundational Manifesto of Agile practices. States the Principles and Values underlying Agile approaches (specifically to Software Development).

In SAFe, the way to assemble and organise a group of teams. Defined and coordinated around a Value Stream of the company.

Agility is a capacity to respond to change. It has come to encompass a whole movement of project or more accurately Product Management techniques, methodologies or philosophies, in reaction to the percieved inadequacy of traditional project management in complex environment. Most notably as opposed to the Waterfall approach to Software Development projects.

Behaviour Driven Development. An Automated Testing focussed approach to software development. It relies on Functional Specifications (written as User Stories according to the Gherkin syntax) to drive the development effort, similarly to TDD, but on a broader scale. Since it is concerned with functional pecifications, it can be an opportunity to foster collaboration between the Business and the Development Team.

A piece of functionality (often imprecisely called User Story). It is the basic unit of work that build up the Product and Sprint Backlogs. A Backlog Item shouldn't be confused with a Task or Technical Specification: it should remain firmly in the Functional domain and provide just enough information for the Team to be capable of assessing its feasibility within an Iteration and confindently start working on it.

The Broken Window Theory comes from criminology. It losely states that small disrepair, minor unfixed damages such as broken windows in a neigbourhood lead to a higher chance of more important issues coming up, and ultimately to an increase in criminality. Applied to Software Development, it is the idea that minor bugs, small defects should be handled just as quickly as major issues, in order to keep the standards of quality high and lower the likeliness of bigger defects to appear.

In software devlopment, a practice aiming at improving code quality (readability, respect of architechtural principles, of coding guidelines,...) by having a peer review of the proposed code changes. Often done through a Pull Request.

Two key metrics in Kanban. Cycle Time measures the process duration from the perspective of the Company: the time between work start and completion. Lead Time measures the process duration from the perspective of the Customer: the time between order and delivery.

In (Scrum, the team responsible for the implementation of the Product. It includes all the people necessary for the implementation (Designers, Developers, Testers, Analysts,...). In opposition, the Scrum Team not only includes the people responsible for the implementation, but the Scrum Master and Product Owner as well.

A formalised syntax for User Stories. When properly implemented, it enables bridging between requirements and acceptance testing, as the written User Stories can then be leveraged and serve as basis for automated acceptance testing, especially in a BDD approach.

In Agile, a common way to make important information directly and constantly visible to the whole team and all passers by. Common examples are the team's Kanban board, Automated Tests status, Incidents monitoring,...

At the core of Agility, inspection and adaptation are two of the most important activities in an empirical process improvement dynamic. Teams will inspect many aspects of their work and process (for instance the Product Increment, at the Sprint Review, the Team's process at the Retrospective,...) and will adapt as necessary, in fact as close as possible to continuously.

A (usually Timeboxed) unit of time during which the Team will work towards the next Product Increment. Called a Sprint in Scrum.

Kanban can either represent a way of work (Kanban method, related to Lean) or, coloquially, the board (an example of Information Radiator) used to visualize the current state of the work (typically in Todo, Doing or Done state).

Large Scale Scrum. A lightweight scaling framework. Presented in a bottom-up approach on how to generalise single-team practices to multi-team products, and on to multi-department (called Areas) situations with LeSS Huge.

Short for Lean Thinking. A term used to encapsulate the set of values and practices found in Toyota's Production System philosophy, which predates and is at the root of modern Agile movements.

Agile methodologies advocate for iterative and incremental development. The Product Increment is the sum of improvements, new features, etc delivered at the end of an Iteration.

The role charged with the responsibility that encompasses all (non technical) concerns linked to the Product (in contrast to a Project). Most notably, it includes market or business justifications, long term vision and strategy, short term changes and evolution, budget handling.

With the Dev Team and the Scrum Master, one of the three Scrum roles. Responsible for the Product vision, through the Product Backlog, its prioritisation and its maintenance.

In software development, a practice meant to enhance code quality, and promote knowledge sharing. When a developer is done with their changes, they introduce a Pull Request, meaning a request for a peer to look at the changes and ensure they meet the team's quality standards (regarding design, architecture, style, automated testing,...). If so, the changes are then pulled (i.e. merged) into the main codebase, and made available to the rest of the team.

A distinction between attitudes in top down management and self-organising teams. in the former, someone will typically assign individual tasks, or push work to team members, whereas in the latter, team members will autonomously pick up the next highest value, available, task to work on when they are done with their previous work item: they will pull work.

A set of methods focussing on getting as close as possible to the root cause of something, as opposed to jumping too early to the solution or improvement proposition part of Inspect and Adapt activities.

Scaled Agile Framework. A full blown scaling framework. Very detailed but quite prescriptive. Very popular currently, as it is well documented and supported. Covers all layers of an Agile company, from recommendations for C-level management to team practices.

A set of approaches aimed at applying Agile to large companies and products. Small scale, single team agile practices are well established, but the community is facing struggle in identifying ways to generalise the practices to more complex, more ambitious situations. The main current approaches are SAFe, Scrum @ Scale, and LeSS.

From the Scrum Guide: A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum recognises three relevant artefacts: the Product Backlog, the Sprint Backlog, and the Product Increment.

With the Dev Team and the Product Owner, one of the three Scrum roles. Responsible for the process, its optimisation, making sure that the team evolves close to true (in spirit) Scrum and Agile.

In Scrum, the team responsible for the Product and its implementation. It includes all the people necessary for the implementation (Designers, Developers, Testers, Analysts,...), the Scrum Master, and the Product Owner. In opposition, the Development Team only includes the people responsible for the implementation.

The non-allocated time in an iteration. Used to handle unforeseen work, small improvements, fix Broken Windows, "Pebble in the Shoe" problems,... At odds with the principle of Utilisation Maximisation dear to traditional management methodologies, Agile approaches recognise the healthy and valuable nature of Slack Time.

In Scrum, the Iteration, or Timebox of a Product Increment. Advised to be between one week and one month long, shorter being often seen as better.

In Scrum, amongst the Artefacts, there are two backlogs: the Sprint Backlog and the Product Backlog. The Sprint Backlog encapsulates the scope of the current Sprint and belongs to the Development Team.

A base unit of work. As opposed to a Backlog Item or User Story, a Task is what is picked up and executed by Team members. In Agile methodologies, Tasks are not assigned to, but taken by team members in a self organizing fashion (Push vs Pull).

An intermediary level between Backlog Item and Task. Gathers the information necessary, from a technical standpoint, to efficiently implement the features responding to the needs of the business. Not systematically used, since Agile promotes Just Enough analysis to start working towards Working Software.

A set period of time used to work towards a goal. When either the goal or the time allocated is reached, the timebox expires. The Sprint in Scrum is an example of a Timebox.

The origin of Lean. If you are beginning your path into Agile, the TPS deserves a bit of your attention, as lots of practices and ideas of Agile movements originated there.

A specific, simple format of functional specification emphasizing the perspective of an end user of the system and what value they seek to derive from the system. Often used interchangeably with Backlog Item, often written according to the Gherkin Syntax.

The attempt to maximize every team member's time utilisation as opposed to their value delivery, one of its worse consequences being the emergence of busy work. This leads to the prevention of Slack Time, mistakenly seen as waste.

Short for Work in Progress Limit. From Lean and Kanban, often applied in Scrum as well, a limit to the number of items, tasks, worked on in parallel.