Agile & Scrum Definitions

A simple way to remember the basic components of Scrum is 3-5-3. Scrum has 3 roles: Product Owner, Scrum Master, Developers (anybody who is working on the sprint increment). Each role has different accountabilities. Scrum has 5 events: Sprint Planning, Sprint, Daily Scrum, Sprint Review, and Sprint Retrospective. Scrum has 3 artifacts: Product Backlog, Sprint Backlog, and Product Increment.

Details just what needs to be done for the Product Backlog Item to be considered complete. This helps teams estimate, test, and accomplish the work. The concepts of Acceptance Criteria and Definition of Done sound very similar, but they are quite distinct.

Test-first software development practice in which acceptance criteria for new functionality are created as automated tests. The failing tests are constructed to pass as development proceeds and acceptance criteria are met.

An acceptance test is a formal description of the behaviour of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios. In many cases, the aim is that it should be possible to automate the execution of such tests by a software tool, either ad-hoc to the Developers or off the shelf.

One of the three Scrum Pillars. If an inspector determines that one or more aspects of a product or process deviate outside acceptable limits and that the resulting product will be unacceptable, the process or the work being done must be adjusted. Sprint Planning Daily Scrum Sprint Review Sprint Retrospective

A movement for finding better ways of developing software. Scrum and Extreme Programming are two leading examples. Others, such as Kanban or Lean Startup do not define themselves in the Agile tradition but are based on compatible values and principles.

Antipatterns are common solutions to common problems where the solution is ineffective and may result in undesired consequences.

Items which represent work or value. There are 3 Artifacts in Scrum; (Product Backlog, Sprint Backlog, and Product Increment).

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

An item that represents a piece of work to be done by the Scrum Team.

Behavior-driven development (BDD) is an agile software development practice that encourages collaboration among developers, quality assurance testers, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.

A pattern for allowing emergent work or interrupts to be brought into the Sprint and worked on as it comes in. The Scrum Team allocates a set amount of story points or capacity to a buffer. This allows flexibility and responsiveness to service. An example is an Interrupt Buffer.

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.

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.

Business agility is the ability of an organization to sense changes internally or externally and respond accordingly in order to deliver value to its customers.

A ritualistic or symbolic activity that is performed on well-defined occasions. Some people refer to the core Scrum activities of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective as ceremonies.

A metaphor used by some Scrum teams to indicate that people are invested in the goal of the Scrum team, but at a level of involvement (not accountable) rather than commitment. Best used to refer to people outside of the Scrum team. Derived from an old joke about a chicken and a pig: “In a ham-and-eggs breakfast, the chicken is involved, but the pig is committed.” Contrast with pigs.

An attribute of source code that is expressed well, formatted correctly and organized for later coders to understand. Clarity is preferred over cleverness.

The quality of the relationship between certain Product Backlog items which may make them worthy of consideration as a whole.

Collective code ownership is the explicit convention that every team member can make changes to any code file as necessary: either to complete a development task, to repair a defect, or to improve the code's overall structure.

One of the five Scrum Values. People personally commit to achieving the goals of the Scrum Team.

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, without doing so manually.

Continuous deployment aims to reduce the time elapsed between writing a line of code and making that code available to users in production. To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.

Continuous Integration (CI) is an agile software development practice popularized by Extreme Programming in which newly checked-in code is built, integrated and tested frequently, generally multiple times a day. It does not provide qualitative information such as code readability.

One of the five Scrum Values. The Scrum Team members have the courage to do the right thing and work on tough problems.

Class Responsibility Collaborator (CRC) Cards are an object oriented design technique teams can use to discuss what a class should know and do and what other classes it interacts with.

A team with all the competencies needed to accomplish work they are given without outside help.Cross-functional teams are proven to be more flexible, creative, and productive than teams that specialize in only one of the competencies needed to get the work done.

Customer development is a four-step framework that provides a way to use a scientific approach to validate assumptions about your product and business.

The definition of done is an agreed upon list of the activities deemed necessary to get a product increment, usually represented by a user story, to a done state by the end of a sprint.

Information needed by the team in order to understand and complete a Product Backlog Item (PBI). Examples include the I.N.V.E.S.T. Criteria. There should be no further conversation or exploration of what is needed for the team to complete the PBI.

Also known simply as the Team, it is comprised of people who work on Sprint Backlog Items. It acts as 'one team' and has all the skills needed to produce a working tested increment each Sprint. The Developers are:Self-Managing Cross-Functional Accountable Small with 3 - 9 team members

The set of standards and practices that Developers identify as needed to create releasable Increments of a product no later than by the end of a Sprint.

An organizational concept bridging the gap between development and operations, in terms of skills, mind-set, practices, and silo mentality. The underlying idea is that developers are aware of—and in daily work consider implications on—operations, and vice versa.

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

The software architecture emerges solely from the decisions the Developers make from a technical perspective.

Process control type in which only the past is accepted as certain and in which decisions are based on observation, experience and experimentation. Empiricism has three pillars: transparency, inspection and adaptation.

A shared set of development and technology standards that Developers apply to create releasable Increments of software.

An epic is a large user story.

The act of predicting how much effort will be needed to complete work on a Product Backlog Item. But without it Product Owners and Scrum Masters will struggle with securing a release date and showing velocity improvement. There are many methods. Most commonly occurs during Product Backlog Refinement.

Exploratory testing is a type of software testing where Test cases are not created in advance but testers check system on the fly. They may note down ideas about what to test before test execution. The focus of exploratory testing is more on testing as a "thinking" activity.

Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for Developers. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.

A facilitator is a person who chooses or is given the explicit role of conducting a meeting.

A series of numbers starting with 0 and 1 where each subsequent number is the sum of the prior two numbers. This leads to significant increases in the value of each number. Fibonacci numbers are often used as a way for Scrum Teams to estimate the amount of effort it will take to complete each Product Backlog Item.

One of the five Scrum Values. Everyone focuses on the work of the Sprint and the goals of the Scrum Team.

The selection of items from the Product Backlog Developers deem feasible for implementation in a Sprint.

An Agile team frequently releases its product into the hands of end users, listening to feedback, whether critical or appreciative.

Functional testing is performed to analyze whether all the functions of your web app works as expected or not. The sections covered in functional testing involves user interface, APIs, database, security, client/server applications, and overall functionality of your website.

The Given-When-Then formula is a template intended to guide the writing of acceptance tests for a User Story: (Given) some context, (When) some action is carried out, (Then) a particular set of observable consequences should obtain.

The team meets regularly to reflect on the most significant events that occurred since the previous such meeting and identify opportunities for improvement.

An acronym that details the elements an individual Product Backlog Item needs to meet in order to meet the Definition of Ready.I - Immediately Actionable N - NEGOTIABLE V - VALUE E - ESTIMABLE S - SMALL T - TESTABLE

Anything that slows the Team down or prevents them from completing work. The key is to identify and remove impediments as quickly and systematically as possible. The Scrum Master helps the team remove impediments and is accountable for surfacing impediments the team can’t remove on their own.

An Increment (sometimes referred to as a 'Potentially Shippable Product') is the value delivered for the customer via the Product Backlog Items completed during a Sprint. Each Increment should interface seamlessly with all prior Increments and stand alone as a distinct addition of value to the Product. While more than one Increment may be created in a Sprint, all work must meet the Definition of Done to be considered complete.

An organizational concept bridging the gap between development and operations, in terms of skills, mind-set, practices, and silo mentality. The underlying idea is that developers are aware of—and in daily work consider implications on—operations, and vice versa.

"Information radiator" is the term for any of a number of visual displays which a team places in a highly visible location, so that all team members can see the latest information at a glance.

One of the three Scrum Pillars. Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work and at Scrum events.

"Integration" (or "integrating") refers to any efforts still required for a project team to deliver a product suitable for release as a functional whole.

In integration testing, the application modules are integrated logically and then tested as a group. It focuses on verifying the data communication between different modules of your web app.

A Scrum pattern. A method of allowing emergent work or interrupts to be brought into the Sprint and worked on as it comes in. The Scrum Team allocates a set amount of Sprint capacity to a buffer. This allows flexibility and responsiveness to service.

An iteration is a timebox during which development takes place. The  duration may vary from project to project and is usually fixed.

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

The Kanban Method is a means to design, manage and improve flow for knowledge work and allows teams to start where they are to drive evolutionary change.

A Kanban Board is a visual workflow tool consisting of multiple columns. Each column represents a different stage in the workflow process.

Lead Time is the time between a customer order and delivery. In software development, it can also be the time between a requirement made and its fulfillment.

A Minimum Marketable Feature is a small, self-contained feature that can be developed quickly and that delivers significant value to the user.

A version of a product which allows a team to collect the maximum amount of validated learning about customers with the least amount of effort.

A Minimum Viable Product is the "version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.

Mock Objects (commonly used in the context of crafting automated unit tests) consist of instantiating a test-specific version of a software component.

Items which represent work or value.There are 3 Artifacts in Scrum; (Product Backlog, Sprint Backlog, and Product Increment).

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

An unofficial extension of a meeting that often follows The Daily Scrum where the members of the Scrum Team discuss in-depth issues, impediments, or topics that go beyond the scope of the Daily Scrum. Only attended by those required to reach resolution on the issues raised.

Performance testing is a software testing process used for testing the speed, response time, stability, reliability, scalability and resource usage of a software application under particular workload. The main purpose of performance testing is to identify and eliminate the performance bottlenecks in the software application.

Personas are synthetic biographies of fictitious users of the future product.

A metaphor used by some Scrum teams to indicate that people are invested in the goal of the Scrum team, but at a level of involvement (not accountable) rather than commitment. Best used to refer to people outside of the Scrum team. Derived from an old joke about a chicken and a pig: “In a ham-and-eggs breakfast, the chicken is involved, but the pig is committed.” Contrast with pigs.

An approach to estimation used by Agile teams. Each team member "plays" a card bearing a numerical value corresponding to a point estimation for a user story.

Agile teams generally prefer to express estimates in units other than the time-honored "man-hours." Possibly the most widespread unit is "story points."

A priority ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A change to be made to the product in a future release (for example a feature, function, requirement, enhancement, or fix). Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones.

A whole team activity led by the Product Owner. The on-going process of adding detail, estimates, and order to the items in the Product Backlog. Not an official Scrum Event, but a highly recommended practice.

Stakeholder input that is analyzed to inform the next iteration, and path of a product or service. Goals of the feedback are to:Validate & Understand how customers interact with the product Capture ideas and emerging requirements for functionality

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

The role in Scrum accountable for maximizing the value of a product, primarily by incrementally managing and expressing business and functional expectations for a product to the Scrum Team.

A description of the incremental nature of how a product will be built and delivered over time, along with the important factors that drive each individual release. Useful when developing a product that will have more than one release.

A brief statement of the desired future state that would be achieved by developing and deploying a product. A good vision should be simple to state and provide a coherent direction to the people who are asked to realize it.

A high-level summary of the project's key success factors displayed on one wall of the team room as a flipchart-sized sheet of paper.

Agility in working software is an aggregation of seven architecturally sensitive attributes: debuggability, extensibility, portability, scalability, securability, testability and understandability.

When "simple design" choices have far-reaching consequences, two or more developers meet for a quick design session at a whiteboard.

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

Refactoring consists of improving the internal structure of an existing program's source code, while preserving its external behavior.

The act of adding detail, estimates, and order to items in a Backlog. The on-going process of adding detail, estimates, and order to the items in the Product Backlog. Not an official Scrum Event, but a highly recommended practice.

Regression testing is performed to verify that a recent change in code doesn’t affect the existing features of your web app. In simple terms, it verifies that the old code works in the same way as they were before making new changes.

Relative estimation consists of estimating tasks or user stories by comparison or by grouping of items of equivalent difficulty.

Collaboratively agree what is to be achieved by a Scrum of Scrums Team using a longer planning horizon than a single Sprint (usually 1-6 months). A Product Owner Team led event used to acquire funding, drive marketing, and align stakeholder/team expectations. A timeboxed event of no more than 4 hours for a one month period.

One of the five Scrum Values. Scrum Team members respect each other to be capable, independent people.

The "role-feature-reason" template is one of the most commonly recommended aids to write user stories: As a ... I want ... So that ...

A specialized function in a particular situation. In Scrum there are three roles: Product Owner, Scrum Master, and Team Member. This simple structure creates clear accountability and efficient communication while removing unneeded bureaucracy.

Rules of Simplicity is a set of criteria, in priority order, proposed by Kent Beck to judge whether some source code is "simple enough."

A framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated roles, events, artifacts, and rules, as defined in the Scrum Guide.

There are three artifacts in Scrum; the Product Backlog, the Sprint Backlog, and Increment. Each artifact contains a commitment to enhancing transparency, focus, and understanding how to measure progress. The commitments for each of the artifacts are: Product Goal for the Product Backlog; Sprint Goal for the Sprint Backlog; and Definition of Done for the Increment.

A physical board to visualize information for and by the Scrum Team, often used to manage Sprint Backlog. Scrum boards are an optional implementation within Scrum to make information visible.

The definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland, co-creators of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.

The role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum.

A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10.

Scrum is founded on empirical process control theory, or empiricism. In turn they are the foundation of every successful Scrum implementation. Three pillars uphold every implementation of empirical process control:Transparency Inspection Adaptation

A self-managing team consisting of a Product Owner, Developers and Scrum Master.

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

The team is responsible for executing the tasks and monitoring and managing process and progress.

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.

Developers normally choose which tasks to work on, rather than being assigned work by a manager.

A team adopting the "simple design" practice bases its software design strategy on a set of "simple design" principles.

Smoke testing is performed to examine whether the deployed build is stable or not. In short, verifying the working process of essential features so that testers can proceed with further testing.

One of the five Scrum Events. It is a short, consistent cycle no longer than four weeks. The goal is to have an iteration short enough to keep the team focused but long enough to deliver a meaningful increment of work. All other Scrum Events take place during a Sprint. Once a Sprint is finished, the next begins

The set of Product Backlog Items selected for the Sprint, plus a plan for delivering the Increment and realizing the Sprint Goal. It includes at least one Improvement identified at the last Sprint Retrospective. It makes visible all of the work the Team identifies as necessary to meet the Sprint Goal.

A tool that makes visible a Scrum Team’s Sprint Backlog and progress during a Sprint. Can take many forms ranging from a digital tool to a three column board labeled ‘Do’, ‘Doing’, ‘Done’. The board is updated by the Team and shows all items that need to be completed, are in progress, or are finished in the Sprint.

The length of a Sprint and set time and date for all events contained in the Sprint.

A short expression of the purpose of a Sprint, often a business problem that is addressed. Functionality might be adjusted during the Sprint in order to achieve the Sprint Goal.

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.

A person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.

Story mapping consists of ordering user stories along two independent dimensions.

Used by Scrum Teams in estimation, an abstract measure of the relative effort required to complete a given Product Backlog Item (PBI). A commonly used type of estimation uses story points and the Fibonacci sequence to quickly generate accurate estimates for PBI’s.

Splitting consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.

The team aims for a work pace that they would be able to sustain indefinitely.

The most basic form of a task board is divided into three columns labeled "To Do," "In Progress," and "Done."  Cards are placed in the columns to reflect the current status of that task.

A "team" in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis.

The team (ideally the whole team, including the product owner or domain expert) has the use of a dedicated space for the duration of the project, set apart from other groups' activities.

A term used to describe the obligation that a software organization incurs when it chooses a design or construction approach that is expedient in the short term but that increases complexity and is more costly in the long term. 2. A metaphor that facilitates the communication between business and technical people regarding implementation artifact inadequacies.

"Test-driven development" is a style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests) and design (in the form of refactoring).

"Card, Conversation, Confirmation" is a formula that captures the components of a User Story.

A common practice at the Daily Scrum following three questions: What have you completed? What will you do next? What is getting in your way?

The organization’s ability to quickly deliver new capabilities, services, or products. Questions that organizations need to continually re-evaluate for T2M are: 1. How fast can the organization learn from new experiments and information? 2. How fast can you adapt based on the information? 3. How fast can you test new ideas with customers?

A timebox is a previously agreed period of time during which a person or a team works steadily towards completion of some goal.

Striving to use the vocabulary of a given business domain, not only in discussions about the requirements for a software product, but in discussions of design as well and all the way into "the product's source code itself."

A unit test is a short program fragment written and maintained by the developers on the product team, which exercises some narrow part of the product's source code and checks the results.

Usability testing is an empirical, exploratory technique to answer questions such as "how would an end user respond to our software under realistic conditions?"

In consultation with the customer or product owner, the team divides up the work to be done into functional increments called "user stories."

When the values of Commitment, Courage, Focus, Openness and Respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and builds trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

An optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team.

Version control is not strictly an Agile "practice" insofar as it is now widespread in the industry as a whole. But it is mentioned here for several reasons.

An agreed upon set of norms, practices, and policies that establish how team members work together.

A pattern in Scrum. A method to help Scrum Teams quickly calculate how many Points they will likely complete in the upcoming Sprint. Usually calculated by using a rolling averaging of the total number of completed points over the past three Sprints.