Glossary

Agile and Drupal Terms

Acceptance Criteria

A set of conditions that are met before deliverables are accepted.

Agile

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods or Agile processes generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Alpha Test

Pre-production product testing to find and eliminate the most obvious design defects or deficiencies, usually in a laboratory setting or in some part of the developing firm’s regular operations, although in some cases it may be done in controlled settings with lead customers. See also beta test and gamma test.

Alpha Testing

A crucial "first look" at the initial design, usually done in-house. The results of the Alpha test either confirm that the product performs according to its specifications or uncovers areas where the product is deficient. The testing environment should try to simulate the conditions under which the product will actually be used as closely as possible.

Assumption

A factor in the planning process considered to be true, real, or certain, without proof or demonstration.

Backlog

Is an ordered list of items representing everything that may be needed to deliver a specific outcome. There are different types of backlogs depending on the type of item they contain and the approach being used.

Backlog Grooming

Is when the product owner and some, or all, of the rest of the team refine the backlog on a regular basis to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.

Baseline

The approved version of a work product that can be changed using formal change control procedures and is used as the basis for comparison to actual results

Beta Test

An external test of pre-production products. The purpose is to test the product for all functions in a breadth of field situations to find those system faults that are more likely to show in actual use than in the firm's more controlled in-house tests before sale to the general market.

Beta Testing

A more extensive test than the Alpha, performed by real users and customers. The purpose of Beta testing is to determine how the product performs in an actual user environment. It is critical that real customers perform this evaluation, not the firm developing the product or a contracted testing company. As with the Alpha test, results of the Beta Test should be carefully evaluated with an eye toward any needed modifications or corrections.

Bug

A error or problem, that is not as per requirements or not meeting acceptance criteria.

Burn-down Chart

A chart which shows the amount of work which is thought to remain in a backlog. Time is shown on the horizontal axis and work remaining on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing work remaining may be expected to fall. The amount of work may be assessed in any of several ways such as user story points or task hours. Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart.

Burn-up Chart

A chart which shows the amount of work which has been completed. Time is shown on the horizontal axis and work completed on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing the work done may be expected to rise. The amount of work may be assessed in any of several ways such as user story points or task hours. The amount of work considered to be in-scope may also be plotted as a line; the burn-up can be expected to approach this line as work is completed.

Daily Scrum

Daily time-boxed event of 15 minutes, or less, for the Development Team to re-plan the next day of development work during a Sprint. Updates are reflected in the Sprint Backlog.

Definition of Done

A shared understanding among the Scrum Team of expectations that the Increment must live up to in order to be releasable into production.

Defect

A missed requirement, missing from the stories and acceptance criteria too.

Deliverable

Any unique and verifiable product, result, or capability to perform a service that is produced to complete a process, phase, or project.

Development Team

The role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Increment of product every Sprint.

Discovery

Is the process of exploring an idea or project. It is an information-gathering process meant to dig deep into the details of an idea or project to gain a better understanding.

Duration

The total number of work periods required to complete an activity or work breakdown structure component, expressed in hours, days, or weeks.

Effort

The number of labor units required to complete a schedule activity or work breakdown structure component, often expressed in hours, days, or weeks.

Epic

A very large user story that is eventually broken down into smaller stories; epics are often used as placeholders for new ideas that have not been thought out fully. There's nothing wrong with having an epic, as long as it is not high priority.

Estimation

The process of agreeing on a size measurement for the stories in a product backlog. Done by the team, usually using Planning Poker.

Fibonacci Sequence

The sequence of numbers where the next number is derived by adding together the previous two (1,2,3,5,8,13,20…); the sequence has the quality of each interval getting larger as the numbers increase; the sequence is often used for Story Points, simply because estimates are always less accurate when dealing with epics.

Gantt Chart

A bar chart of schedule information where activities are listed on the vertical axis, dates are shown on the horizontal axis, and activity durations are shown as horizontal bars placed according to start and finish dates.

Issue

A certainty that will affect the outcome of a project, either negatively or positively. Issues require investigation as to their potential impacts, and decisions about how to deal with them. Open issues are those for which the appropriate actions have not been resolved, while closed issues are ones that the team has dealt with successfully.

Impediments

Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the daily Scrum meeting. The Scrum Master is charged with ensuring impediments get resolved. Scrum Masters often arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting.

Iterative

Agile projects are iterative insofar as they intentionally allow for "repeating" software development activities, and for potentially "revisiting" the same work products (the phrase "planned rework" is sometimes used; refactoring is a good example).

Incremental Development

In an Agile context, Incremental Development is when each successive version of a product is usable, and each builds upon the previous version by adding user-visible functionality.

Lessons Learned

The knowledge gained during a project which shows how project events were addressed or should be addressed in the future for the purpose of improving future performance.

Level of Effort - LOE

An activity that does not produce definitive end products and is measured by the passage of time.

Milestone

A significant point or event in a project, program, or portfolio.

Milestone Schedule

A type of schedule that presents milestones with planned dates.

Minimum viable product (MVP)

Is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product's initial users.

Product Life Cycle

The series of phases that represent the evolution of a product, from concept through delivery, growth, maturity, and to retirement.

Project Life Cycle

The series of phases that a project passes through from its initiation to its closure.

Project Phase

A collection of logically related project activities that culminates in the completion of one or more deliverables.

Project Schedule

An output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources.

Ready

A shared understanding by the Product Owner and the Development Team regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.

Release

The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it. "The product is released to customer or marketplace obligations.

Retrospective

The sprint retrospective is a meeting facilitated by the Scrum Master at which the team discusses the just-concluded sprint and determines what could be changed that might make the next sprint more productive. The sprint review looks at _what _the team is building, whereas the retrospective looks at _how _they are building it.

Requirement

A condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.

Risk

An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.

Risk Acceptance

A risk response strategy whereby the project team decides to acknowledge the risk and not take any action unless the risk occurs.

Risk Appetite

The degree of uncertainty an organization or individual is willing to accept in anticipation of a reward.

Risk Avoidance

A risk response strategy whereby the project team acts to eliminate the threat or protect the project from its impact.

Risk Exposure

An aggregate measure of the potential impact of all risks at any given point in time in a project, program, or portfolio.

Risk Mitigation

A risk response strategy whereby the project team acts to decrease the probability of occurrence or impact of a threat.

Scope Creep

The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.

Scrum

Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely-used one. A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes. These and other terms used in Scrum are defined below. Scrum is most often used to manage complex software and product development, using iterative and incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to classic “waterfall” processes. Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals.

Scrum Team

A self-organizing team consisting of a Product Owner, Development Team and Scrum Master.

Self-organization

The management principle that teams autonomously organize their work. Self-organization happens within boundaries and against given goals. Teams choose how best to accomplish their work, rather than being directed by others outside the team.

Sponsor

An individual or a group that provides resources and support for the project, program, or portfolio, and is accountable for enabling success.

Sprint

Time-boxed event of 14 days, or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps.

Sprint Backlog

An overview of the development work to realize a Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality.

Sprint Planning

Time-boxed event of 8 hours, or less, to start a Sprint. It serves for the Scrum Team to inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint backlog.

Sprint Retrospective

Time-boxed event of 3 hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint.

Sprint Review

Time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period.

Stakeholder

An individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.

Story Point

A unit of measurement applied to the size of a story, cf. Fibonacci Sequence T-shirt sizes, powers of 2, are other ways of assigning Story Points.

User Acceptance Testing

A test conducted by the customer to determine if the requirements of a specification or contract are met.

User story

Is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.

Velocity

In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning. Once established, velocity can be used to plan projects and forecast release and product completion dates.

Waterfall

The waterfall model is a linear sequential (non-iterative) design approach for software development, in which progress flowing in one direction downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.

Work Breakdown Structure (WBS)

A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.