What is Agile?

A/B Testing

A way to make comparative tests with the intent of revealing which of two options is better. In order for A/B testing to work, there must be a way to quantify the results.

AC - Actual Cost

The actual dollar amount spent by a team for work performed during a set period of time. This usually is the payroll costs for the entire development team plus any actual material costs associated with work done during a sprint.

ACWP - Actual Cost of Work Performed

Same as AC

Adjourning

(See Bruce Tuckman)

Aging Analysis

A method used in WIP analysis to determine which jobs have been in the queue an inordinate length of time. These engineering jobs frequently are experiencing unexpected difficulties, and action is needed such as assigning experts to solve the problems or to perhaps employ an automated escalation process. (See Automated Escalation)

Agile

Agile is an umbrella term that encompasses a number of frameworks, software development and management best practices. Scrum is a part of Agile. The Agile approach is especially effective in circumstances where there are; hard to define requirements, needs for high quality, high chances for frequent or ongoing changes to occur, seasoned and skilled team members available, personnel open to change and doing things in a new way, and a total corporate management that is pro Agile.

ADAPT

An acronym for the five activities needed for a successful switch over to Agile.

A = Awareness that there is a problem with the current system.
D = Desire to adopt Scrum to solve these problems.
A = Ability to succeed with Scrum because the knowledge is available.
P = Promotion of Agile methodology throughout the company to highlight its benefits.
T = Transfer of the implications of using Scrum throughout the non-IT departments of the co.

Agile Engineering

Agile engineering refers to the group of practices that includes TDD (test driven development), automated testing, CI (continuous integration), and automated deployment. The purpose of agile engineering is to automate all repetitive tasks to save development team time, and to improve code quality by way of using automated testing to retest everything for which a test already exists. Agile engineering also involves the identification of best development practices, such as TDD, that does not add any additional downstream developer time and improves code quality.

Agile Manifesto

A statement of values and principles that describe the various Agile processes of which Scrum is one. Developed in 2001 the manifesto contains a total of twelve principles.

Agile Release Train (ART)

A composite of usually 50 to 125 people broken down into individual teams of 5 to 9 all dedicated to working on one of the company’s value streams. For a very large organization, there can be a number of value streams being worked on at the same time each one of which will have a release train of multiple teams.

Agile Release Train Engineer (RTE)

The person who serves as the Chief ScrumMaster of the train. That person arranges for Scrum of Scrum meetings and is key in Release Planning and workshops. He or she is the overall coordinator of the train teams and works closely with all of the individual team ScrumMasters.

Agilist

The agile practitioner.

Artifacts

By-products that are produced and come into existence as the project is being worked on. They can be thought of as useable tools to the project’s implementation. They have value in that they provide transparency to the status of the project’s implementation. Examples would be burndown charts or product backlogs.

ATDD

Agile Test Driven Development (See TDD)

Automated Escalation

A tool used when engineering jobs are stuck in a WIP queue for a long length of time. The priorities of these jobs, which many times have low priorities, are automatically escalated to a higher level. When used care must be taken since we are using criteria other than economic to prioritize at a higher level. If, for example, we are pushing back a high cost of delay job we may want to leave things at the status quo.

Backlog Grooming

Refers to the refining or grooming of the product backlog by the development team. As work is completed more information becomes available for further defining and detailing of future items to be worked on.

Batch Size Adjusting

Increasing or decreasing the amount of work in a given batch in order to respond to changing economic conditions as a project progresses along.

Batch Size - Optimum

Optimum batch size is a function of holding and transaction costs. By lowering transaction costs, a lower optimum batch size is created. Two synonymous terms are Economic Order Quantity (EOQ) and Economic Lot Size (ELS).

Batch Size Reduction

A key technique to be tried first to reduce cycle time and queue size. Reducing batch sizes also reduces variability in flow and accelerates feedback in product development situations. Reducing batch size should also be tried first as an alternative to increasing capacity. There are other pluses to reducing batch sizes and only minor harm regarding increased costs if the batch size in too low.

“Battle Hardened”

Development team members who have worked on intense large scale application development projects.

“Big Agile”

The overall Agile philosophy for project management and implementation. (See “Little Agile”)

Boundaries

The limits or constraints a Product Owner puts on a project that the development team must adhere to. Examples would be completion time deadlines and cost limits. The constraints the Product Owner asks for must be realistic and possible to attain.

Bruce Tuckman

A long time researcher into the theory of group dynamics. In 1965 he published his forming, storming, norming, and performing model and later in the seventies added a fifth stage called adjourning. All five stages are helpful explanations of team development and behavior and are explained below:

Forming - This is the initial stage where a new development team begins to work together for the first time. There is a heavy reliance on the ScrumMaster for guidance. The SM is bombarded with questions and requests for direction. Team members in this stage are skeptical of the new system and the ability of the ScrumMaster.
Storming - This second stage is wrought with infighting as the team begins to work together in earnest. The leader (SM) urges team members to focus more on accomplishing goals rather than on their personal relationships.
Norming - In stage three team members agree to and accept what their roles are going to be on the team. They become committed and unified. The SM switches more to a coach than a director.
Performing - In this stage the team knows what it is doing and can solve in a positive way its own problems and disagreements. It functions well on its own. Here future team leaders emerge who later may become project leaders (SMs) themselves. Here the SM is more involved in solving external problems that affect the team’s performance.
Adjourning - This final stage is more of an off-shoot of the first four stages and is stand alone. It involves the dissolvement of the team once the entire project has been completed. It deals with the insecurity of team members who became used to and happy working as a team.

Budgeted Cost of Work Scheduled (BCWS)

(See Planned Value)

Burndown Chart

A visual display showing the amount of work remaining to be completed in a sprint or project. Work to be done is shown on the vertical axis and the amount of time left usually expressed in days, on the horizontal axis. The trend line is downward and when it crosses the horizontal axis is the date the work is likely to be completed; either before, after, or on schedule.

Burnup Chart

Like the burndown chart measures work completed over time. The basic difference is that it shows the total amount of work to be done in the project as a whole and then as work is being completed plots it on an ascending trend line.

Cadence

The consistent, regular pace that events take place. The speed of an event’s cadence can be increased or decreased by a decision to do so, but otherwise, it remains constant and does not vary. For example, in Scrum, the length of a Sprint may be set-up as two weeks long. Its cadence then is twenty-six per year. A Daily Scrum meeting has a cadence of every day of a sprint minus the days when we have the planning meeting and the demo and retrospective meetings. Setting up cadences is very important because in a sequential process it helps prevent variability from accumulating.

Capability Maturity Model (CMM)

A framework that describes practices an organization uses in developing software. There are five levels; one is undefined, and five is highly defined and has repeatable practices for developing software.

Collocated Team

A development team or teams that are in the exact same physical location. (See also Distributed Teams)

Collective Ownership

Where development team members are allowed to modify each other’s code. The dual responsibility then results. The purpose is to ensure that no coder becomes solely specialized so that he or she can’t contribute in other areas other than their specialty; and also to make sure no area is understood or worked on by a single developer (coder).

Communities of Practice

Any like-minded group like ETC and IC, who come together to enhance a common cause.

Component Team

A team that develops software to be delivered to another software team rather than to the end user or customer. Traditionally teams were set up as component teams. (See also Feature team).

Continuous Integration

Where team programmers add code a number of times per day. It’s usually achieved with the help of a tool or script that notices when the code has been added to the system. An important part of continuous integration is to test any new code added to be sure it works with the code already completed. The key benefit of continuous integration is that if there is a conflict you know about it immediately.

COD - Cost of Delay

Relates to the fact that the more delay time there is in implementing a value-added feature in a project that has a high cost of delay the more the cost will be because of the delay in receiving additional ROI. From an economic point of view, it is usually best to do high cost of delay lobs first. This means knowing how to figure the cost of delay before prioritizing.

Critical Fractile

The anticipated demand level that optimizes expected profits.
Culture - In IT it refers to the “mindset” of the organization meaning what is commonly done on a repeating basis by most everyone in the company. The mindset might be Waterfall, Agile, etc.

Cumulative Flow Diagram (CFD)

A tool for understanding queueing problems and their causes.

Cycle Time

Cycle time is a term that can be used to measure many different kinds of operations and is essentially the time that it takes for an operation to be completed from start to finish. In agile, development cycle time is the measurement of time from when a requirement enters the backlog until the time that it is deployed into production.

Daily Scrum Meeting

A 15-minute time-boxed meeting held at the same time each workday that is attended by the development team and the ScrumMaster. At this meeting, each team member gives a short account of what they accomplished the previous day and what they will be working on that day. Any constraints or problems they ran into are also stated. Only team members speak at this meeting.

Daily stand-up meeting

Same as a Daily Scrum Meeting only one where the team members stand up while giving their reports. The reason for standing is to keep the meeting as short as possible.

Demo Meeting

(See Sprint Review Meeting)

Development Team

These are the people who do the primary work on a project. They have cross-functional skills and are responsible for producing completed, tested, debugged code, and proper documentation. Along with technical skills, ability to communicate is important for all team members. Team size can vary from as little as two to over seventy. Scrum recommends a team size of five to nine.

Difficulty Points

(See Story Points and Velocity)

Distributed Teams

Multiple teams in a scaled project that are not located in the same physical location. The teams working on the same project could be located anywhere in the world and in different time zones. They might even speak different languages. A single team can also be distributed if its members are scattered in different locations.

DOD

Department of Defense

Done, or Definition of Done

In Scrum it refers to a useable portion of work ready for implementation that has been completed by the development team. To be considered done the work must meet all standards and guidelines that all parties previously agreed to. The criteria for what constitutes “done” can vary between teams, but to ensure transparency all parties must be clear about what done means.

Earned Value (EV)

The actual value of the work a team completed in a set period of time (sprint). In an Agile team framework, it is expressed in Story Points. (Difficulty points)

Earned Value Management (EVM)

A project management methodology where actual value of work performed (EV) is compared to planned value of work performed (PV)

ELS - Economic Lot Size

(See Batch Size-Optimum)

Emergence

The process of a new fact, or knowledge of a new fact coming into existence or prominence. Also, knowledge of a fact becoming visible unexpectedly.

Empiricism

A process control method or practice in which only the past is accepted as certain and where decisions are based on observation, experience, and experimentation rather than theory. Empiricism has three pillars: transparency, inspection, and adoption.

Engineering standards

A shared set of development and technology standards that a development team follows while creating releasable increments of software.

Enterprise Transition Community (ETC)

A group of up to twelve senior level people in an organization involved in the successful transition to Scrum. The ETC is responsible for coming up with the Master Improvement Backlog. The ETC team can do the work itself in Scrum fashion or delegate it to a Scrum team to do.

EOQ

Economic Order Quantity (See Batch Size-Optimum)

Epic Owner

Within the SAFe (scaled agile framework), the epic owner is the person that follows the epic from the time that the epic enters the epic backlog until the requirements described in the backlog have been coded, accepted and are in production.

Evo (Evolutionary Value Delivery)

A methodology developed by Tom Glib in the 1960s consisting primarily of incremental product delivery where value added product increments are released for the stakeholders use as soon as they are completed rather than at the end of the total project. Another key element of Evo is processed iteration. This is where the entire software cycle of plan, design, develop, test, document, and release is done repeatedly in a mini fashion in a series of sprints.

Extreme Programming (XP)

A methodology for teams developing software to use when there are rapidly changing requirements. It's planning approach is incremental, and it relies on doing automated testing frequently in order to catch and correct defects early on. The use of pair programming is also part of XP.

Feature creep

The tendency for development team members to add additional features to a product because it is relatively easy to do so even though it was not originally called for. The danger is that there are additional costs for adding on each new feature. There can also be a significant cost of delay if the release of the basic product has to wait for all the add-ons to be completed first.

Feature Team

A team set-up to produce product value sooner with the goal of getting it into the user’s hands asap. In Scrum and Agile it is ideal to have all feature teams, but sometimes component teams may be necessary.

FIFO

An acronym meaning first-in-first-out.

Forecast (of functionality)

The items selected from the product backlog that a development team believes it can complete in an upcoming sprint.
Forming (see Bruce Tuckman)

Functional Design Specification (FDS)

Functionality

Refers to a unit of work in a project that when completed by the development team will be deliverable and have a business value. The unit of work will fulfill a user or customer requested desire and therefore have functionality.

Grow and Split

(See Team Expansion)

Hardening

The period of time when teams have completed development and are repairing identified defects in coding before a release.

Hawthorne Effect

A psychological study of many years ago that found an individual’s productivity increased in response to their awareness of being observed.

HLL

A computer programming High-Level Language.

Iceberg

A Scrum term referring to the similarity of the Product Backlog to an iceberg. A Product Backlog is made up of a small amount of highly defined visible requirements and a very large amount of only broadly defined ones. (Still unseen below the water line)

Improvement Community (IC)

A group of people who work together to improve the organization’s use of Scrum.

Increment

A fully functional segment of working software that was completed during a sprint according to Scrum standards. Once tested to be sure they function together the sum of all increments equals a product.

Incremental Product Delivery

(See Evo)

Internal Coaching

(See Team Expansion)

Invisible Inventory

In software product development refers to information since “inventory” is both physically and financially invisible.

Iteration

A repeating event. In Scrum, it refers to one cycle within a project or a sprint. If a project is made up of ten sprints, there would be ten iterations all of the same fixed length.

Internal Managers

These are internal company managers who can have an important influence on whether or not a development team is successful. They have control over several important factors such as work space and personnel.

Just In Time

A term meaning having information or components available exactly at the time they are needed. In Agile and Scrum, it refers to large features being split up and details added to small features “just in time” as they move up the prioritized product backlog. In manufacturing, it means having component parts available just before they are needed on the assembly lines to keep carrying costs of inventory as low as possible.

Kaizen

A Japanese term meaning continuous incremental improvement.

Kanban

A Japanese term for a pull system where a Kanban card is used. It is a system that acts to constrain local WIP pools. (See pull system)

Lean Thinking

See TPS (Toyota Production System)

“Little Agile”

The specific methodology to improve the quality, speed of completion, and success of project outputs. Scrum is a part of “Little Agile”.

Little’s Formula

(See Wait Time)

Metrics

In IT, a set of measurements set-up primarily to monitor how well a development team is doing. Metrics commonly used are:

1. Sprint success rate
2. Team velocity
3. Team morale
4. Sprint burndown chart
5. Rework due to undetected defects
6. Release burnup chart
7. Customer satisfaction ratings based on customer questionnaires.

Minimum viable product (MVP)

Minimum, prioritized, logical work segments in the product backlog that can be completed and implemented asap to provide ROI asap.

Mix Leveling

This is mixing in easy jobs with difficult jobs when scheduling to avoid long runs of just difficult jobs. This leveling usually prevents queue time from increasing.

Nexus

A Scrum framework that is used in a scaled project where there are approximately 3 to 9 Scrum teams and a common product backlog. The Nexus framework is in addition to and overlays the existing scaled Agile (Scrum) framework. Its core is a Nexus Integration Team. See also Nexus Integration Team.

Nexus Integration Team

A team consisting of a Product Owner, ScrumMaster, and one or more integration team members. The purpose of the Nexus team is to coordinate the work of all the multiple Scrum teams to be sure their value added product output ties together and is in harmony and not conflict. The need for a Nexus integration team becomes very important when there are a large number of Scrum teams all working on the same project using the same product backlog. And if the teams are not colocated, it becomes even more necessary. (See also Nexus)

Norming

(see Bruce Tuckman)

Optimum Queue Size

The optimum queue size (lot size) is that quantity where there is an exact balance between cost of capacity and cost of delay.

Pair Programming

Two programmers working together to write code. Benefits are:

1. Decrease in total time to complete the project.
2. Better quality.
3. Facilitates knowledge transfer.
4. Better for solving difficult problems.

Performing

(see Bruce Tuckman)

Planned Value (PV)

The value of work, usually expressed in Story Points, that an Agile team thinks it can complete during a set period of time (sprint). See also Earned Value (EV).

Process Iteration

(See Evo)

Processing Rate

Cycle time to complete an operation or function.

Product Backlog

A prioritized list of project requirements with estimated times for their completion. Estimated times are more precise for requirements scheduled close in than out in the future. The list is constantly subject to adds, changes, and deletions due to business changes and stakeholder feedback.

Product Owner

One person who represents the wants and desires of the stakeholders and works closely with the development team and Scrum Master in the implementation of a project. He or she is responsible for creating and maintaining the product backlog which is a prioritized list of project requirements. He or she is responsible for the success of the team in realizing the project’s goals.

Pull System

A lean manufacturing process where line workers indicate by use of a Kanban card when they are close to being out of parts.

PWS (Performance Work Statement)

A type of contract endorsed by the DOD (Department of Defense) between a company and a software consulting firm which lists the goals or value streams the company is hiring the consulting firm to develop and implement. This type of contract is consistent with Agile principles in that it is not rigid and allows for evolvement and change as the project is being developed. See also SOW (Statement of Work).

Queue

Jobs waiting in a line to be completed that are usually prioritized. The longer jobs spend waiting in a queue, the more adversely cycle time, quality, and efficiency are affected.

Queueing Discipline

The method used to sequence jobs in a queue. When all jobs take the same time to complete Queueing Discipline does not matter. They all have the same cost of delay. In manufacturing this is many times the case and a first in first out (FIFO) queueing discipline is used.

Random Early Deletions (RED) and Random Early Marking (REM)

Two techniques used especially by the Internet to reduce (throttle) WIP flow. These two methods begin reducing flow before a buffer is full. The purpose is to provide reserve margin for handling demand surges.

Rate Matching

To force the average rate of arrival into a queue pool to match (equal) the average rate of departure from the pool. This is done by limiting the amount of new work coming into work-in-process (WIP).

Ready

A shared understanding by the Product Owner and development team of what the preferred level of description should be for product backlog items to be introduced at a sprint planning meeting.

Refactoring

The refining or cleaning up of code. Refactoring does not change the behavior of code but rather its structure. The goal is to improve the basic structure of the code to minimize the need for future interventions to correct flaws in its design. A good Agile development team will spend a significant amount of time each sprint doing refactoring. If teams do not, numerous, major future “fixes” will slowly “rot” the system to the point where no more fixes are possible, and the entire system must be rewritten. If enough time has gone by the rewriting can be a major problem especially if the original coders are no longer with the organization and the coding was not documented well.

Release

A part of an Agile project that is broken down into a number of sprints. The release length is the sum of all the sprints it contains. The sum of all the releases make up the roadmap for the project. (See also Roadmap)

Release Train (RT)

(See Agile Release Train)

Release Train Engineer (RTE)

(See Agile Release Train Engineer)

ROI

Return on investment

Roadmap

The overview of the entire Agile project. During a roadmap planning session, it is broken down into releases first and then further into sprints.

Rolling Wave Planning

An Agile approach where the work to be done in the next sprint is done in detail. The farther out work is scheduled to be done the less detail planning it receives. The idea is not to detail work scheduled far out as there are likely to be changes that would necessitate rework.

RPG

Report Program Generator - An IBM proprietary programming language used for business applications. First available by IBM in 1959 it has been upgraded over the years into RPG IV, a high-level language similar to PL/1 and Cobol.

Safety Stock

In manufacturing the extra inventory carried on parts, sub-assemblies, or products as a hedge against running out of stock. Its drawback is the increase in inventory carrying costs.

Safety Time

(See Time-Buffers)

Scaled Agile project

When more than one Scrum team works simultaneously on a project.

Scaling

D1. Refers to the work being done simultaneously by multiple teams on the same project. On a scaled project mechanisms must first be set-up to coordinate the work of the teams, and non-functional requirements defined and added to the Product Backlog. Since both business and non-functional requirements can be tasks in a sprint, it is necessary that the non-business requirement is completed first if the business requirement is dependent on it.
D2. Sizing a team to fit the work effort. Normally this is done when the work effort is small. Small scale teams may also be formed for a program that will have a large about of work over a long time frame, but the work requirements are generated at a pace that allows a team smaller than five people to accomplish.

Scrum

Scrum is a specific methodology that uses Agile principles along with its own set of standardized practices and terminology. Scrum can be thought of as a part of Agile. It is not an acronym. Under Scrum project goals are broken down into logical work segments that are prioritized with the goal of being able to complete and implement them asap to maximize return on investment.

Scrum Board

A physical board where messages can be posted that a development team can use to manage the sprint backlog. Scrum boards are optional but serve as an aid to provide development teams with information visibility.

Scrum Values

A set of fundamental values and qualities underpinning the Scrum framework: commitment, focus, openness, respect, and courage.

Scrumban

Scrumban uses the same framework as Scrum, but it incorporates the Kanban pull system to supply user stories to the development team. The sprint planning meeting differs from Scrum because no work is defined as part of the sprint, instead, the work is drawn from the prioritized backlog and velocity is determined at the end of the sprint.

Scrum Master

The person who is the coach, mentor, and protector of the development team. He or she is also the main enforcer to ensure that the development team is performing according to scrum rules and processes. A Scrum Master can be thought of as a project leader who adheres to Scrum and Agile rules. A good Scrum Master will coach and guide rather than solve a team’s problems by himself or herself.

Scrum of Scrums

A meeting of ScrumMasters on coordinating the work of the multiple development teams they are coaching.

Scrum team

The Scrum Team consists of a Scrum Master, development team, and a Product Owner. They are self-organizing teams who choose how best to accomplish their work without being directed and managed by others outside of the team.

Self-Organization

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

Sequencing

The order in which jobs are completed in a Sprint. In Agile and Scrum, those jobs that give the maximum value for the least cost are prioritized to be done first.

Sequential Approach

Traditional project management approach where one phase of the work is completed before going on to the next one. There is no overlapping of phases. The phases were usually heavy planning followed by coding, testing, debugging, documentation, and lastly, release to the user or customer. The sequential approach is not in agreement with Agile and Scrum principles but in some instances in project development it may be appropriate.

Servant-Leader

A manager who acts as a coach and aide to a team and helps remove any obstacles they may run into while working on a project. A two-word definition of a ScrumMaster.

Set Based Concurrent Engineering (SBCE)

Parallel development of backup solutions. Requires careful cost analysis and may be unnecessary if Agile and Scrum techniques are properly used.

Silo

A specific domain area.

SOW (Statement of Work)

The traditional contract between a company and a consulting firm stating in detail what the requirements are that make up the new project the consulting firm was hired to develop and implement. Internal company personnel may or may not participate in the project’s development. The SOW contract is not compatible with Agile principles. See also PWS (Performance Work Statement) which is compatible.

Split and Seed

(See Team Expansion)

Sprint

The amount of prioritized work a development team thinks it can complete in a time-box of one month or less. The time length of each sprint is determined before the first sprint begins and remains constant for however many sprints it takes to complete the entire project. If, for example, it is estimated it will take 20 weeks to complete the entire project and the sprint length is to be two weeks, then there will be a total of 10 sprints of 2 weeks each. Each sprint can be thought of like a mini-project in itself. During the sprint quality goals should not lessen and changes should not be made unless, because of knowledge learned as the sprint progresses, clarification or renegotiation becomes necessary between the Product Owner and the development team. Since sprints are for relatively short periods of time, they rarely are canceled. If they are, for say the project’s goal becoming suddenly obsolete, then only the Product Owner can do so.

Sprint 0

Is the only Sprint that does not have a specific length. The purpose of the sprint 0 is to do everything that is necessary to prepare for and align all of the details needed to get the development sprints started. The typical deliverables from sprint zero include, staffing, development environment set-up, developing the roadmap, developing and confirming the vision, developing the initial product backlog, include defining the epics, writing the user stories for at least one Sprint, and any other-other set-up tasks that are determined to be necessary before starting the first sprint. (Also see Staging)

Sprint Backlog Report

A list of tasks a development team thinks it can complete during the next sprint. Responsibility is assigned to each task along with estimated time to complete As the team works on the sprint more tasks will be added as analysis occurs. The sprint backlog report also shows the amount of work remaining on a task on any given day during the sprint.

Sprint Goal/Theme

A short expression depicting the purpose of a sprint; often a business problem that needs to be addressed. During a sprint, functionality may have to be adjusted to accommodate the emergence of new facts that affect the sprint goal.

Sprint Planning Meeting

A one-day meeting broken down into two, four-hour time-boxed segments that are held shortly before each sprint begins. In the first segment, the development team selects from the product backlog those prioritized items it believes it can complete and turn into increments of value added material during the upcoming sprint. In the second segment, the development team decides how it will meet the commitments made in the first meeting. Their output is a sprint backlog report.

Sprint Review Meeting

A meeting held at the end of each sprint that is time-boxed to 4 hours. During this meeting, the development team demonstrates to the Product Owner and stakeholders what they accomplished as completed product during the sprint. Only completed (done) product is demonstrated. The sprint review meeting is also known as a “demo” meeting.

Sprint Retrospective Meeting

A meeting held at the end of each sprint that is time-boxed to 3 hours. It is usually held after the sprint review meeting or the next day. The purpose of the meeting is for the development team to discuss what went well and what did not during the just completed sprint and how future sprints could be improved upon to make them more productive.

Staging

The defining and prioritizing of non-functional requirements that must be done before work can start on a scaled project. It is a one-day meeting to provide the infrastructure for a clean interface among multiple teams working simultaneously on a project. Work on the first sprint should not begin by any team until the infrastructure requirements have been defined and added to the Product Backlog as high priority items. Ideally, they should be completed first before scaling can be started in earnest.

Stakeholder

Anyone who has an interest in the outcome of a project. They are either funding it, will be using what it produces, or will somehow be affected by it.

Storming

(see Bruce Tuckman)

Story Points

A numeric unit of measure for showing the size and/or complexity of a User Story, Feature, or Task. There is some but no direct correlation between the number of story points and the number of hours to complete. Usually scored on a scale of one to ten.

Takt Time

The repeating time length of a manufacturing process (its cadence). If for example, an assembly line turns out four vacuum cleaners per minute, its takt time is 15 seconds.

Tasks

The lowest level of Agile project work that a development team can work on. The task must be able to be completed in one sprint. The other levels from top to bottom are Epic, Feature, User story, and Task. Aside from tasks, the others are usually too large to be completed in one sprint and are further broken down.

Team Setup

Initially team members should be selected by functional managers, product owners, ScrumMasters, and Scrum consultants. Candidates should be consulted for their input especially if they have Agile or Scrum knowledge. (See also Team Expansion).

Team Expansion

There are three ways to create additional Scrum teams once the first team is becoming successful.

1. Split and seed: The first team is split in two, and new members are added to both teams.
2. Grow and Split: Add new members gradually to the first team and then when large enough split into two equally numbered teams. Initially, the two new teams will be on the small side of the 5 to 9 total team members Scrum recommends.
3. Internal Coaching: One member who is best at Scrum in a successful team is appointed as a coach to help other teams having trouble. Coaches stay with their original teams but have less time available for that team’s work.

Technical Debt

The cost of adding to code that was originally written in a flawed or incomplete fashion. Technical debt also occurs when the latest releases are not incorporated promptly. Carrying technical debt is not necessarily bad as it can mean getting a new product out sooner when speed is critical and slipshod code is better than no code. The goal, however, should always be to reduce technical debt before it gets out of hand and becomes almost impossible to correct.

Technical Design Specification (TDS)

Test Driven Development (TDD)

refactoring which is a critical element of TDD). TDD is an Agile process where a programmer a few times per hour will repeatedly perform three functions: write a failing, automated test; write just enough code to pass the failing test, and then clean up the code (refactor).

Theory of Constraint (TOC)

A concept developed by Eli Goldratt in his book “The Goal”. The theory says to only release work into the system at the operating rate of the bottleneck. Useful in manufacturing where there usually are stable bottlenecks but not as useful in product development where there are frequently unpredictable or short duration bottlenecks.

Time-buffers

Adding time to complete a cycle to reduce variability in cycle time. Buffers reduce variability but increase cost in direct proportion to the amount of safety time (buffer time) added to the cycle. In general, it is not a good idea to trade cycle time for reduced variability.

Time-box

A fixed period of time that is predetermined for an event or meeting to occur. It can not be exceeded even though the work scheduled was not entirely completed.

Total Cost

In software development refers to Cost of Capacity plus Cost of Delay.

TPS - (Toyota Production System)

Developed by W. Edwards Deming, Taichi Ohno, and Shigeo Shingo at the end of WWII. In 1996 it became the basis for the book “Lean Thinking” by Jim Womack and Dan Jones.

Transparency

Providing artifacts (tools) that allow all members of a project team to have complete visibility of the progress being made on the project they are all working on. Charts, graphs, test and backlog reports are all examples of artifacts. Transparency occurs when everyone is “on the same page”.

User Requirement Specification (URS)

User Stories

A broad definition of what a user or customer wants from a new project. The user stories are further broken down into tasks that make up the product backlog.

Variability

The likelihood a project will be subject to change or alteration. Traditionally change was considered a bad thing and extensive up front planning was done to anticipate and minimize changes. In today’s world minimizing changes (variability) is not a valid goal in design development. Minimizing the economic impact of change is, however, a valid goal.

Velocity

The rate at which a development team as a whole converts backlog items to completed in a single sprint. It is usually calculated in story points and is a measure of team efficiency. It is very useful in helping to determine how many story points that the team can take on in the following sprint. If for example, a team accomplished 70 story points of work in sprint one they should estimate that they can complete about the same amount in sprint 2. Velocity is tracked by the Development Team for use within the Scrum Team.

Wait time

Based on Little’s formula it means queue size divided by processing rate (cycle time).

Waterfall

The traditional way of doing project work in which the various processes are done sequentially. Usually, the sequence is heavy planning, followed by coding, testing, debugging, documentation, and lastly implementation. Waterfall is still a valid approach in circumstances where there are definite and highly defined requirements, little risk of change, rigid compliance and contract issues, inexperienced and/or unskilled team members, and a rigid, anti-change corporate culture.

Wave

A term synonymous with a sprint. (See Rolling Wave Planning)

Webinars

A Web seminar is an on-line lesson or seminar that hundreds of people can participate in simultaneously. There are two basic types of Webinars; one is designed to educate and build brand awareness to eventually generate sales leads, and the other to directly sell product that can be purchased immediately.

WIP

Work in process

WIP Constraints

The techniques used to avoid high work-in-process inventory The simplest one is to block new arrivals when queue size becomes large. Increasing capacity is another way to keep excess WIP inventory down as incoming arrivals increase. There are many other techniques for reducing WIP queue size, but most all of the methods have pros and cons.

XP

Extreme Programming is similar to Agile Engineering (see Agile Engineering) with the most significant difference being ideas like developers working until any code that has broken a development build be fixed before they leave. Rigid practices like this caused XP to lose popularity.