Team Practices Group/Glossary

NOTE: Definitions are a work-in-progress. Terms will be added or removed as needed. Italics indicate terms which do not yet have definitions here.

Agile
"Agile" is a mindset, not a specific process. As such, it does not call for the use of any specifc practices or ceremonies. People often confuse the concept of agile development with specific agile methodologies such as Scrum or Extreme Programming, or with specific agile practices such as Incremental Development or Daily Standup meetings.

Agile was developed in the 1990's as a response to the dominant software development paradigms of the time. which were "No process" and "Heavy process". The heavy processes of the time, which were typically some form of Waterfall, often required massive requirements documents and massive design documents to be created and approved, before single line of code would get written. It was frustrating for both developers and customers, and the failure rate of software projects (whether they used heavy processes or no processes) was insanely high. At first, this new alternative approach was known as "lightweight" development, but that had negative connotations, so they renamed it to agile.

Agile changed the focus from the process and tools to the people doing the work. It de-emphasized documentation in favor of working code. And it embraced responding to change over following a plan. The highest priority of agile is to satisfy the customer, and another priority is "technical excellence and good design".

Agile Manifesto
A public declaration that launched the Agile movement

Backlog
A list of tasks (features, defect fixes, etc) that need to be done. Backlogs are a key artifact of the Scrum process. For details, see Product Backlog and Sprint Backlog.

Blocker criteria
A set of standards for determining if a work item (e.g. defect, feature, or change request) would delay a release. These standards set minimum requirements for changes to a codebase which is changing and driving towards a product release with a specified set of features. Blocker criteria are also used to minimize introducing new regressions into a codebase.

Bug
The term "bug" is often used as a catchall to mean a code defect, requirements oversight, feature request, improvement, task, or any other technical work. Generally, it is better to use a more specific term, to avoid confusion. Wikipedia article.

Burndown chart
A graphical representation of work (for example, defect fixes) remaining in a project versus time. A burn down chart helps teams predict when work for a given project will be completed, and to track progress. You can view a sample burn-down chart on Phabricator here:

Continual (or continuous) improvement
An ongoing effort of constantly evaluating and improving processes in the light of their efficiency, effectiveness and flexibility. It is a key part of Scrum (with its retrospective at the end of each sprint), and is one of the 12 principles behind the Agile Manifesto.

This can take the form of regularly scheduled retrospectives, along with tangible actions afterwards to actually improve. Or it can be that everyone involved in the process is actively encouraged to look for improvements every single day. Regardless of the implementation details, the important thing is that there is a culture that encourages processes and practices to keep improving over time.

As a side note, "continuous improvement" has traditionally been used, but "continual" is technically more accurate, and is used by ISO in its standards.

Daily scrum (meeting)
The Scrum process requires the team to hold a brief daily "scrum" meeting.

During the meeting, each team member answers three questions: Typically, the daily scrum is a "standup" meeting, where to encourage brevity, everyone remains standing.
 * What did I do yesterday that helped the Development Team meet the Sprint Goal?
 * What will I do today to help the Development Team meet the Sprint Goal?
 * Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Daily standup (meeting)
A common agile practice, where the team meets briefly each day to share status, blockers, or other helpful information. The name ("standup") comes from the convention of not sitting down, to encourage brevity. The Scrum process requires daily team meetings, and defines a very specific agenda for them (see Daily Scrum).

Defect
An error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended or undesired ways.

Deliver
Make a product available to a wide end-user audience. Also called Deploy, Release, or Ship.

Deploy
Make a product available to a wide end-user audience. Also called Deliver, Release, or Ship.

Epic (a type of story)
An Epic is a type of Story that represents a larger amount of work than can be captured in a normal User Story. It is typically too large to fit within a single iteration, and is often difficult to estimate reliably. The distinction between Story and Epic is subjective, so it is up to a team to define the boundaries.

Examples of Epics might be a large specific feature, such as "allow visual editing", or a multi-faceted initiative such as "make the site work better on mobile devices".

Iteration
In agile terms, an iteration is a quantity of time and work, resulting in a potentially shippable product. Typically this would have the team working for a few weeks, after which the product would be improved, and would be tested and documented enough that it could be put into production. Iterations are almost always measured in weeks, and are most often 2 or 3 weeks long.

In the Scrum process, iterations are known as "sprints" (see Sprint). Kanban doesn't specify fixed-length iterations.

Kanban (a methodology)
Originally developed for managing manufacturing processes (see JIT and Lean), Kanban has been adapted to software development as a very light agile process. It is much less prescriptive than Scrum, relying on the team to decide which practices, artifacts, and ceremonies it will use.

Commonly, work is split into small-ish tasks (less than one developer-week), and these tasks are treated as a continuous stream of work. Tasks enter the system, may go through several states such as "in progress" or "needs review", and eventually end up exiting the system as "done". A Kanban board closely resembles a Scrum task board, with each state represented by a column.

Unlike Scrum, in Kanban there are no fixed-length iterations. Instead, work steadily flows through the system. As a result, the Product Owner can change which tasks will be worked on next at the last minute, as long as work hasn't actually started.

One key concept in Kanban is limiting work-in-progress ("WIP"). Generally this is represented by each column in the board having a maximum number of tasks that it can hold. If a column is full, then before a new task enters, a task must proceed to the following column in order to free up space. While this sounds like a simple technicality, it actually has significant effects on the system. Limiting WIP and reducing the batch size force the work to flow at a more steady pace, improving flow, and increasing the overall speed of the team.

Continuous improvement is another critical aspect of Kanban. Team members are also encourged to continuously be on the watch for potential improvements, and regular formal retrospectives are encouraged. Wikipedia article.

Potentially shippable product
A product that has met the release criteria. This does not mean that the product will be released immediately. A product could be ready to ship, but not actually ship until a later date.

Product backlog
In Scrum, the list of tasks that need to be completed in order to deliver a viable product, ordered by priority. This list can contain features, defect fixes, and non-functional requirements, and is managed by the Product Owner. Wikipedia article:

Release (verb)
Make a product available to a wide end-user audience. Also called Deliver, Deploy, or Ship.

Release Criteria
A set of standards and features that must be met in order for a product to be released to a general audience. Before a product can be ready to ship, it has to be tested and improved for stability, performance, defects, usability, etc. Release criteria guide this process, ensuring that user meets are met and that a product reaches a certain level of quality before being released.

Retrospective
A discussion held at some milestone point (such as at the end of an iteration, or after a release), where a team can reflect on that experience. Typical questions include "what went well?" and "what could have gone better?" There are many different templates for thThe goal is future improvement, not blaming or scapegoating for what went wrong.

The quarterly WMF Team Health checks are a form of retrospective. Scrum requires the team to have a Sprint Retrospective at the end of each iteration, which is typically every 2-3 weeks.

Other common names for retrospectives include "sunset review", and "post-mortem".

Scrum (a methodology)
"Scrum is an empirical Agile project management framework used to deliver increments of high value to the customer iteratively. Scrum relies on self organizing, empowered teams to deliver the product increments. It also relies on a customer, or Product Owner, to provide a team with a list of desired features using business value as the priority mechanism. (from http://epf.eclipse.org/wikis/scrum/)"

A Scrum team consists of a Product Owner (who often has the Product Manager title), a Scrum Master, and the development team (often referred to as just "the team"). Each product increment is developed during an iteration known as a Sprint, which is less than one month long. By the end of each iteration, the product must be Potentially Shippable. The team meets each day for a Daily Scrum (often called a Standup). Each sprint begins with a Sprint Meeting, where the team chooses a set of high-priority stories from the backlog, and commits to completing them during this iteration (thus forming the Sprint Backlog). Each sprint ends with a Sprint Review meeting (where stakeholders see what was developed), and a Retrospective. During a sprint, only the development team is allowed to add tasks to the sprint backlog.

The Product Owner acts as the single voice of the customer and other stakeholders. He or she determines the strategic direction of the product, and prioritizes the work according to its value. The Scrum Master is a facilitator and obstacle-remover, enforcing the process and buffering the team from distractions.

Scrum is a relatively "lightweight" agile process, specifying only a few roles and ceremonies. It does not specify particular coding techniques, estimation methods, or other practices. That makes it much easier to adopt than a more prescriptive methodology like Extreme Programming, although there are even lighter options such as Kanban.

Wikipedia article

Scrum (a meeting)
Teams following the Scrum process meet daily in a brief "scrum" meeting. See Daily Scrum.

Scrum of scrums
An extension of the Scrum methodology, which improves coordination of multiple Scrum teams working on the same product. Each Scrum team sends a representive to the Scrum of Scrums meetings, which take a form similar to a Daily Scrum: Each person says what their team has worked on since the last meeting, what it will be working on until the next meeting, and whether they are facing any obstacles. They should also mention if they are about to create an obstacle that would affect other teams. The focus is on inter-team dependencies and obstacles.

Ship (verb)
Make a product available to a wide end-user audience. Also called Deliver, Deploy, or Release.

Sprint
In the Scrum process, each iteration is called a "sprint". A Sprint is a fixed amount of time (a "timebox" of up to one month), during which the team has committed to a specific set of work, and is focused on completing it. Each sprint starts with a Sprint Planning meeting to define the scope, and ends with a Sprint Review meeting (showing the results) and a Sprint Retrospective meeting (for continuous improvement).

Note that despite the name "sprint", the pace of work is expected to be steady and sustainable. Also see Iteration.

Sprint backlog
In Scrum, the list of tasks (features, defects fixes, etc.) which the team has committed to complete during the current sprint. This backlog is managed by the team, and once a sprint has started, only the team can add items to the sprint backlog. Wikipedia article:

Sprint retrospective
A retrospective meeting held by Scrum teams at the end of each Sprint (iteration). See Retrospective.

Standup (meeting)
A short meeting, often held daily. The name comes from the common practice of having all attendees stand up during the meeting, to encourage brevity. See also Daily Standup and Daily Scrum.

Story
A brief summary in common language describing a user feature. Typically they are short enough to fit on an index card or, and often they are written in sentence form like "As a  , I want  so that  ". Unlike a full use case or detailed requirement, they only capture the essence of the feature, and primarily serve as a reminder of a conversation between the person(s) defining the user interaction and the person(s) implementing the feature. A story is one type of task that might appear in a Backlog.

User story
A brief summary in common language describing a user feature. The term User Story originated in Extreme Programming, but is often shortened to just "story". See Story.

Velocity
A measurement of how much work a team got done within a specific time period, or an average over multiple time periods. For example, a team that estimates using Story Points, and who works in 2-week iterations, might report a velocity of "18 points per iteration". This does not necessarily mean that they would be able to complete 18 points in future iterations, but is often used as a ballpark guess of how much work to commit to for an upcoming iteration.

Some important notes about velocity:
 * It should measure how many estimated units got completed, not how much actual time was spent
 * It is only meaningful at a team level, not per individual
 * Velocities can never be meaningfully compared between teams
 * It is most informative when estimates over time are consistent (not necessarily accurate)
 * It is heavily dependent on the availability of team members within each iteration
 * Incentives based on velocity are counter-productive

Wikipedia article

Online Agile glossaries:

 * http://www.solutionsiq.com/agile-glossary/
 * http://agiledictionary.com
 * http://www.telerik.com/teampulse/agile-vocabulary
 * http://www.innolution.com/resources/glossary
 * http://www.scrumstudy.com/search.asp