Team Practices Group/Glossary

Information on this page has been collected or prepared by members of the Team Practices Group for experimentation, discussion, and validation. It is not meant to be authoritative or prescriptive for WMF staff or community members.

Introduction

This document is intended to clarify these terms as they are used within the Wikimedia Foundation teams and broader community. There are several related or similar glossaries, some of which are listed in the #Online Agile glossaries: section.

Definitions

Acceptance testing

Testing, usually manual, in order to judge whether or not completed software development meets the needs of the end user. Usually performed by a representative sampling of end users, by a paying customer, or by a Product Owner or other proxy for end users.

Action item

A task that must be carried out by a single individual or a group of people. Action items generally arise from meetings and are documented.

Agile

"Agile"[1] is a mindset, not a specific process. As such, it does not call for the use of any specific practices or ceremonies. People often confuse the concept of agile development with specific agile methodologies such as #Scrum (a methodology) or #Extreme Programming (XP, a methodology), or with specific agile practices such as Incremental Development or #Daily standup (meeting).

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 (a methodology), often required massive requirements documents and massive design documents to be created and approved, before a 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 shifted away from a predictive model to one of adaptation. The highest priority of agile is to satisfy the customer, and another priority is "technical excellence and good design". The agile mindset is captured nicely by the #Agile Manifesto.

Agile coach

A person who works with a team to implement or improve an Agile process. May perform duties within that process, such as Scrum Master, or may assist or train other people in roles.

Agile Manifesto

A public declaration[2] that launched the #Agile movement. The gist of it is valuing:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Artifact

A document or other persistent collection of data used to track and communicate information.

Automated testing

Tests that are executed without human intervention.

Backlog

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

Backlog grooming

An activity performed by the #Product Owner, possibly with assistance from other team members or in a meeting with the whole team, to improve the quality of the backlog so that #Sprint planning meetings will be better and easier. Backlog grooming partially replaces traditional Requirements Gathering. Can include any of:

Creating #User stories
- working with other stakeholders to define stories
- work identification, creating #Epics and Stories
- work breakdown, splitting existing Epics and Stories
Refining stories
- Adding Acceptance criteria
- Developing a story narrative
- Adding possible designs (UI design, algorithm design, input/output design, etc)
- Identifying use cases and linking them to stories
- #Estimation (if a team does not do this in Sprint Planning)
Reprioritizing the backlog
Removing stories
- Merging duplicate or overlapping stories
- Removing obsolete stories

Batch size

The unit of work that passes from one stage to the next stage in a process. For example, from "Being Coded" to "Being Tested", or from "Needs Review" to "Done".

#Lean development favors working in small batches, which have the benefit of moving through the entire system faster. This allows validation and learning to happen faster by getting those units to the end user sooner. Reducing batch size is an important practice of #Kanban (a process)

Blocker

Any problem that prevents progress. It may be a #Task that blocks another task, or blocks a #Release or other major milestone. Examples of non-task blockers would be a lack of necessary knowledge to perform some work, or a critical system being down, or an expert being unavailable for consultations.

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.

Bottleneck Burnup

A Cumulative Flow Burnup in which stories spend the bulk of the sprint in an intermediate state, such as In Testing, and the Sprint finishes with a small percentage of stories finished. This may indicate a bottleneck in the intermediate state, such as a lack of available staff.

Sprint Cumulative Flow Burnup with bottleneck

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. Burndown charts are most often used to track progress within an #Iteration or toward a major release.

Burnup chart

A modification of the Sprint Burndown chart. Instead of showing one line representing the total remaining points to be completed (i.e., Committed - Done), a burnup chart shows completed points over time (Done) with one line and Committed with a separate line. This makes it possible to see which changes in (Committed - Done) are due to changes in each of the two variables separated.

A burnup chart can also be constructed for an entire project over multiple sprints. The chart below shows uncertainty in the velocity.

Business value

The value of a Story to its end users, which may be very different from the amount of work required to complete it.

Capacity

In Scrum, the number of Story points a team expects to complete each sprint, based on historical Velocity and any particular changes in the upcoming sprint, such as holidays, vacation, and other availability limits of team members.

Ceremony

"[T]hose process activities you must perform to keep your development work on track." Rick Freedman ^[2] In Scrum, ceremony refers to the standard meetings in which basic Scrum activities are performed: daily Standup, and Sprint Planning, Review, and Retrospective.

Certified Scrum Master (CSM)

A Scrum Master who has passed a test offered by scrumalliance.org. CSM's take a course, usually 2 days, from a Certified Scrum Trainer, followed by the test for certification.

Code review

The review of code by one or more peers. Produces quality improvements comparable with many forms of testing.

Code smell

An informal indication of the quality of code, typically in terms of maintainability and of adherence to coding standards and best practices. May also indicate technical debt.

Co-located team

A team where all members are physically present in the same office.

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 (a methodology) (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.

Continuous delivery/deployment

A method of software development in which the product available to users is updated very frequently, often immediately after #Defects are fixed or new #Features are added and tested. The amount of time from fix to #Delivery could literally be just a few minutes.

This is in contrast to traditional development cycles where the product is #Deployed every 6 months to 2 years (or longer). Many agile projects fall in the middle, with releases every 1 to 4 weeks.

Continuous integration

A method of software development in which changes to the code are merged into the main branch of code frequently, perhaps daily, or perhaps immediately after each change is committed.

Ideally, the integration includes running automated tests to at least ensure that nothing major was broken by the new changes. Continuous integration is often referred to as "CI", and one popular CI tool is named Jenkins.

The act of starting work on a task to such a degree that it is most logical that the person who started the task (the licker) follow through, rather than another individual completing that task (or the licker wasting time by not finishing a task that they started).

Cross-functional team

A team whose members have a broad range of relevant skills. An example might be a team consisting of a UI designer, software developers, testers, a data analyst, and a product manager.

Cumulative Flow Burnup Chart

A burnup chart with separate lines for each different story state (e.g., In Development, In Testing).

Customer

The person or entity who will use a product, and/or are responsible for supporting development, or their representatives or proxies.

Cycle Time

The time it takes a piece of work to travel between the beginning and ending points within a process. Some spans that may be measured by cycle time includes: a Scrum Story from Committed to Done; software patches from date submitted to date reviewed or resolved; bugs from time reported to time triaged, or to time resolved.

Daily scrum (meeting)

#Scrum (a methodology) requires the team to hold a brief daily "scrum" meeting (Wikipedia article).

During the meeting, each team member answers three questions:

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?^[3]

Typically, the daily scrum is a "#Standup (meeting)" meeting, where to encourage brevity, everyone remains standing.

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. #Scrum (a methodology) requires daily team meetings, and defines a very specific agenda for them (see #Daily scrum (meeting)).

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. A heuristic for differentiating bugs from features is, a bug reflects a discrepancy between the intended and actual behavior.

Deliver

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

Deploy

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

Distributed team

A team in which one or more members are geographically separated from other team members.

Done

A formal term in Scrum that refers to the acceptance of a story as complete by the Product Owner. In Scrum, a Story that is not completed to the shared understanding of the Product Owner and developer is not Done. The shared understanding may be documented in Acceptance Criteria, but these are intended as a memory aid, not a contract to mediate disputes.

A Story which meets the shared understanding but does not completely address the Customer's need is still Done, and new Stories should be created to address gaps.

Done-done

A term used to clarify variations in Doneness and ambiguity between colloquial use and the specific definition of Done in Scrum or in a team's norms.

Emergent architecture

A method of software development in which software architecture decisions are made in the smallest possible increments in direct support of immediate development concerns.

Emergent design

As with Emergent Architecture, for interface or internal design.

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".

Estimation

The process of estimating the level of effort of an individual unit of work or a larger project. Distinct from Forecasting, which predicts when a unit of work will be finished, based on estimation or via other methods.

Extreme Programming (XP, a methodology)

A software development methodology which advocates frequent releases in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of pair programming.

Fail-fast

A fail-fast system is designed to immediately report at its interface any failure or condition that is likely to lead to failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. Such designs often check the system's state at several points in an operation, so any failures can be detected early. A fail-fast module passes the responsibility for handling errors, but not detecting them, to the next-higher system design level.

Feature

A slice of functionality. It can be split into a collection of smaller user stories that implemented together will deliver the value of a feature.^[4]

Feature creep

The ongoing expansion or addition of new features in a product, such as in computer software.^[5]

Feature-driven development (FDD, a practice)

This is a set of practices focused on delivering user value. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.^[6]

Fibonacci sequence (for estimation)

A standard practice in Scrum is to estimate all stories to a set of values based the Fibonacci sequence. Typically, this is 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. This sequence is particularly helpful for Scrum estimation because the relationship between the numbers is fairly similar to how humans perceive differences in uncertainty.

Flow (a state of being)

In positive psychology, flow, also known as zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does. Conditions of flow are defined as a state in which challenges and skills are equally matched.

Hockey Stick Burnup

A Cumulative Flow Burnup in which the bulk of stories which are finished are finished at the very end of the sprint. This may indicate that the team should work on smaller stories or commit to less work in progress.

Impediment

An impediment is anything that prevents a Team Member from progressing on their #Tasks. The Team Member is responsible for reporting the impediment, and the #Scrum Master is responsible for resolving it or escalating resolution. Impediments may be #Blockers.

Information radiator

A physical or virtual display of information in a highly visible or easy to access location. Examples could include a physical scrum board on a wall in an office or a dashboard for a live service.

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 #Delivered. Iterations are almost always measured in weeks, and are most often 2 or 3 weeks long.

In #Scrum (a methodology), iterations are known as "#Sprints". #Kanban (a methodology) doesn't specify fixed-length iterations.

Iteration zero

An initial #Iteration performed by a new team. Goals may include creating infrastructure necessary to work on the project, developing an initial [#Backlog]] of #Tasks, or learning and practicing the process itself. "Iteration zero" often produces no useful product, but if possible, it should.

Just-in-time (JIT)

A production system or supply chain which delivers resources at the moment they are needed.

Kanban (a process)

NOTE: The word "Kanban" can be used in many different ways, to mean many different things. This entry completely ignores several definitions, including at least 2 kinds of Kanban process or methodology. Even within the software development context, there isn't a single universal definition. The primary source material for the description below is the book "Kanban in Action", by Hammarberg and Sunden.

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 (a methodology), 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 #Task 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. When space opens up in a column, it effectively pulls a finished task from the previous column. While this sounds like a simple technicality, it actually has significant effects on the system. Limiting WIP and reducing the #Batch size allow (and/or force) the work to move through the system at a more steady pace, improving flow, and increasing the overall speed of the team.

#Continual (or continuous) improvement is another critical aspect of Kanban. Team members are also encouraged to continuously be on the watch for potential improvements, and regular formal #Retrospectives are encouraged. Wikipedia article.

Last Responsible Moment

The last chance to make a decision, before further delay starts to become costly or problematic. This term was coined as a counter to the "Last Possible Moment", recognizing that waiting until literally the last possible moment may be irresponsible.

In agile development, it is generally a good thing to wait until the last responsible moment before making a decision.

Milestone

"A significant point or event in a project, program, or portfolio."^[7] A Milestone "should describe a desired state of affairs, a desired future situation."^[8]

Minimum marketable feature (MMF)

Closely related to #Minimum viable product (MVP). MVP is more commonly used, so is generally preferable.

Minimum releasable features (MRF)

Closely related to #Minimum viable product (MVP). MVP is more commonly used, so is generally preferable.

Minimum viable product (MVP)

In product development, the minimum viable product (MVP) is the product with the highest return on investment versus risk. A minimum viable product has just those core features that allow the product to be deployed, and no more.

The MVP concept can also be applied to a single feature: What are the minimum aspects of that feature which would result in a viable product that creates user value? When viewed with a critical eye, many aspects which appear necessary at first can be postponed until later releases, allowing an initial barebones implementation of a feature to be delivered quickly.

Whether at a product or feature level, delivering only the MVP has several benefits:

Lower cost to develop (and test, document, maintain)
Value is delivered to users earlier
User feedback can determine which omitted aspects are highly valued by users, and which are not

MoSCoW

A technique for quick prioritization, by assigning all requirements to exactly one of the following buckets:

M=MUST

S=SHOULD

C=COULD

W=WON'T

Open Kanban (a methodology)

Open Kanban was created in response to widespread confusion and disagreement about the meaning of #Kanban (a methodology) as it relates to software development. It documents a handful of values and general practices which define an "ultra-light method". It can serve as a foundation upon which a team can define a process, which might up looking somewhat like "#Scrum (a methodology) without fixed iterations".

The values are:

Respect for people
Courage
Focus on value (and not waste)
Communication and collaboration
Holistic or systemic approach to change

The practices are:

Visualize the workflow

(e.g. on a workboard)

Lead using a team approach

(e.g. self-directed team)

Reduce the #Batch size

(e.g. work on small stories, serially)

Learn and improve continuously

Similar to #Scrum (a methodology), Open Kanban does not require or prohibit detailed practices such as testing and pair programming. However, where Scrum does require specific practices like fixed-length iterations, and ceremonies like the #Daily Scrum, Open Kanban leaves it up to the team to determine what works best. The only requirement is that such decisions are subject to #Continual (or continuous) improvement.

Open Kanban is released under an open license (CC BY).

Phabricator

Phabricator is a suite of web-based software development collaboration tools. It is available as free software under the Apache License, version 2. Phabricator was originally developed as an internal tool at Facebook, and is embraced at the WMF for its open-source nature.

Planning poker

A tool used for group #Estimation, in which a group of people discuss and clarify a task until they all feel ready to estimate, then estimate independently in #Story points (by each selecting numbers in a deck of cards, chat room, or other tool and revealing them simultaneously), then discuss outlier estimates and converge on a final answer via discussion and/or re-vote.

Points

See #Story points.

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 (a methodology), 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: [3]

Product Owner

In Scrum, a Product Owner is the voice of the user/customer. They condense feedback from stakeholders into a prioritized backlog. They have the ability to say "No" to proposed features or products. They are ultimately responsible for the finished features or product. They are often called "The last wring-able neck".

Refactoring

Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior.

Regression

A #Defect which was fixed in a previous [[#Release (noun)]|#Release], but has manifested again.

Regression Testing

Testing which is specifically intended to re-test issues known to be fixed to ensure that regression problems are identified as quickly as possible, so that they can be more easily tracked to their source, and so that the product's quality does not regress.

Release (noun)

A specific version of a software product, intended to meet Release Criteria and be #Delivered.

Release (verb)

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

Release Criteria

A set of standards and features that must be met in order for a product to be #Delivered 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.

Release train

A metaphor for a series of fixed-date releases in sequence, such that work in progress that is not quite ready for one release can readily be included in the next release fairly soon, limiting the motivation to delay releases.

Retrospective

A discussion held at some milestone point (such as at the end of an #Iteration, or after a #Deployment), 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 the format. The goal is future improvement, not blaming or scapegoating for what went wrong.

The quarterly WMF Team Health checks are a form of retrospective. #Scrum (a methodology) 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".

Quality

The properties of software, other than intentional functionality, that determine how it functions. Typically includes defects, security, accessibility, regulatory compliance, and performance among other attributes.

Saga

A Saga is a type of #Story that is bigger than an #Epic. Beyond that, there is no firm definition.

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 result must be a #Potentially shippable product. The team meets each day for a #Daily scrum (meeting) (often referred to as a #Standup (meeting)). Each sprint begins with a #Sprint planning 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 (XP, a methodology), although there are even lighter options such as #Kanban (a methodology).

Wikipedia article

Scrum (a meeting)

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

Scrumban

Scrum-ban is a software production model based on #Scrum (a methodology) and #Kanban (a methodology). Scrum-ban is especially suited for maintenance projects with frequent and unexpected work items or programming errors. In such cases the time-limited sprints of the scrum model are of no appreciable use, but scrum's daily events and other practices can be applied, depending on the team and the situation at hand.

Scrumbut

When a team is "doing scrum, but...." That is, a team has adopted some or most #Scrum practices, but not all of them. Generally a derogatory term, although for some teams doing not-quite-Scrum might actually be ideal.

Scrum of scrums

An extension of #Scrum (a methodology), which improves coordination of multiple Scrum teams working on the same product. Each Scrum team sends a representative to the Scrum of Scrums meetings, which take a form similar to a #Daily scrum (meeting): 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 (such as #Blockers. 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.

Scrum Master

A formal role in #Scrum (a methodology), the Scrum Master is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The Scrum Master is not a traditional team lead or project manager, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the scrum process is used as intended. The Scrum Master helps ensure the team follows the agreed scrum processes, often facilitates key sessions, and encourages the team to improve. The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.

Scrum team

The development team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each sprint (the sprint goal). A team is made up of 3 to 9 individuals who do the actual work (analyze, design, develop, test, technical communication, document, etc.). Development teams are cross-functional, with all of the skills as a team necessary to create a product increment. The development team in scrum is self-organizing.

Self-organization

A process where some form of overall order or coordination arises out of the local interactions between the components of an initially disordered system. ^[9]

A team might be self-organizing at one or more levels:

Execution of its work
Monitoring and managing its work
Designing its processes and interfaces with external entities
Setting its overall direction, mission, or goals

Ship (verb)

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

Shirt sizing (estimation)

#Estimation by grouping many items into a small number of different sizes, e.g., Small, Medium, Large. Some teams find it easier to deal with abstracted names, rather than to assign numeric values to sizes, as is done with #Story points or estimating in actual hours/days/weeks.

Shovel-Ready

A Story that is sufficiently detailed to be estimated in a Sprint Planning meeting.

Spike

An problem or open question which will require an indeterminate amount of work to resolve. To be useful, a Spike should have a well-defined outcome, e.g., "figure out which database to use", and be completable within a Sprint. Spikes do not have Story Points, and are a compromise to incorporate but constrain un-estimated work within a Scrum.

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 #Continual (or continuous) improvement).

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

Sprint backlog

In #Scrum (a methodology), the list of #Tasks (#Features, #Defect fixes, etc.) which the team has committed to complete during the current #Sprint (aka #Iteration). 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: [4]

Sprint goal

A single goal for a scrum iteration. It helps focus the team and give context to their work.

Sprint planning meeting

As part of #Scrum (a methodology), at the beginning of a #sprint, the team holds a sprint planning event:

Select what work is to be done
Prepare the sprint backlog that details the time it will take to do that work, with the entire team
Identify and communicate how much of the work is likely to be done during that sprint

Sprint retrospective

A #Retrospective meeting held by teams using #Scrum (a methodology), at the end of each #Sprint (aka #Iteration) to assess and improve the project's process and environment.

Sprint review

A meeting held by Scrum teams at the end of each Sprint to observe all completed Stories and judge which ones are Done.

Stakeholder

A person or group interested in or affected by a project.

Standup (meeting)

A short meeting, often held daily, to communicate status. The name comes from the common practice of having all attendees stand up during the meeting, to encourage brevity. See also #Daily standup (meeting) and #Daily scrum (meeting). A standup is intended solely for information sharing, not for problem-solving.

Story

A brief summary in common language describing a user #Feature. Typically they are short enough to fit on an index card, and often they are written in sentence form like "As a <role>, I want <goal/desire> so that <benefit>". 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.

Story points

A unitless measure that indicates the amount of work required to complete a Story. A Story Point is intended to capture both the amount of work likely required to complete a Story, and the risk inherent in the Story.

Storyboard

A physical board, or virtual representation thereof in a computer tool, which shows tasks in a grid, where each column represents a different status. Rows may indicate priority, order of entry, or nothing in particular.

Sustainable pace

A level of team productivity which can be maintained without jeopardizing the product or team health while still meeting project requirements.

Task

A discrete piece of work required to finish a Story, fix a Bug, remove an Impediment, or otherwise advance some other objective. A good task should have most of the characteristics of SMART.

Task board

Any chart, bulletin borad or virtual UI which holds and displays tasks. Task boards frequently display critical information like, deliverables, state of progress and owner.

Technical debt

The degree to which short-term decisions have compromised the ability of a software product to meet longer-term needs. Stories which reduce technical debt may have little or no immediate benefit to users. The concepts of accumulating and discharging technical debt provide a way to think and make decisions about short-term vs long-term needs.

Technical stories

A Story which does not directly involve a user of the product but is helpful or necessary to development. In the form "As an X, I want to Y so that Z", X is a developer, database administrator, or other member of the team or support for the team. For example, "As a developer, I want to port a software library to this project's programming language, so that we can use it to complete other Stories more quickly."

Test-driven development (TDD, a practice)

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.

Timebox

A development cycle with a fixed ending. This may mean that development stops on a fixed date, followed by a decision on how to proceed. It may also refer to a software release that is scheduled for a fixed time regardless of feature development.

Use case

A scenario in which the software may be used. Used to describe and divide the ways in which software may be used, in order to validate requirements, design, and functionality incrementally.

V-Model (a methodology)

Based on the core of #Waterfall (a methodology), V-Model is a "heavy" software development methodology which is becoming popular in some industries (such as medical equipment and parts of the defense industry).

Vertical slice

An intermediate product which demonstrates what progress on each system of a larger project.

In video games, it is a proof of concept which demonstrates the potential of the finished production in art and systems performance.

Waterfall (a methodology)

The waterfall methodology is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance. This contrasts with the #Agile methodology.

Work in progress (WIP)

Work that has been started but not finished. #Kanban (a process) and other lean philosophies tend to emphasize limiting or reducing WIP as a way of increasing efficiency and productivity.

Unit testing

A test, usually automated, which validates a small and self-contained piece of code in isolation from other code.

User story

A brief summary in common language describing a user #Feature. The term "User Story" originated in #Extreme Programming (XP, a methodology), but it is often shortened to just #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