Generic name that often means the opposite of a rigid and heavyweight software development and/or project management approach or process.

Document drafted during a meeting in Utah in 2001, which initiated a more adaptive and lightweight movement in software development.

The overall design or arrangement of the main components of a software application.

Similar to what some other people call architecture intent, this is a high-level vision of what the architecture will look like once all the details are fleshed out.

Diagram used by the Scrum team to display how much work remains in the Sprint.

The art of developing someone’s talents or helping someone grow or reach some specific goals by helping the person identify his own roadmap and commitments that will be required of him to get to the results.

Teams are self-organizing in Scrum; these are techniques that project team members can use to resolve conflicts among themselves: Accommodating, Compromise, Competitive, Collaborating, and Avoidance.

Data elements that relate to the core of the business domain or to the organization’s business. Room and reservation are, for example, core data elements of a hotel, while book and patron are core data elements of a library. Designing and building software applications around these core data elements ensures the long-term stability of the software product and helps extend it more easily into the future without the excessive costs of rebuild.

Simple rules that a Scrum team can use to validate its user stories (while gathering requirements). CUTFIT stands for Consistent, Unambiguous, Testable, Feasible, Independent, and Traceable.

The team that is responsible for all the software development activities within a Scrum team, from writing requirements to designing to coding and testing.

A daily progress meeting where the team members get together, physically or virtually, to synchronize and learn how much they have progressed towards the Sprint goal. Three questions have to be answered during this meeting:

Agreement by all the three parties of the Scrum team as to what the end state is supposed to be for the development team by the end of the sprint.

High-level blueprint of a company’s eco-system that shows the relationship and inter-dependencies between its business vision, strategy, processes, software applications, data, and infrastructure.

A team, which exists in many IT organizations, that is responsible for the overall architecture of the company’s IT systems and with which the Scrum team often must interact to get their project’s application approved and to ensure that their new application architecture fits into the overall enterprise architecture.

Still called a Sprint in Scrum, this is a time-boxed cycle in Scrum during which the development team is asked to turn some selected (prioritized) user stories into an increment of potentially shippable product.

A process improvement framework famous for its contribution to the Toyota Production System (TPS).

Denotes a card and technique, derived from the broader Kanban framework, which is used to limit work-in-process, thus, increasing workflow.

Generic name that covers all processes or techniques, which is known to eliminate waste from a system or process.

An increment of working software product that was developed during a Sprint and which can be eventually shipped to customers.

A team within many IT departments that is in charge of business and IT alignment and tracking IT performance, mainly in terms of project costs, benefits, and timely delivery.

A member of the Scrum team who is responsible for the product vision, product backlog items (requirements), and their prioritization, from a business perspective. In some cases, the product owner is required to play the mediation role between different business units within a company in order to prioritize their conflicting business needs and requirements.

A team with many IT departments, which is responsible for quality assurance and testing activities of all new software development. It is not part of the Scrum process framework but is a unit with which the Scrum team must interact, even if only to get a testing professional to be loaned to the Scrum project team to create a cross-functional capability.

Meeting during which the product owner shares with the Scrum team his product vision and what functionality, in terms of user stories, should be delivered by when. With the architectural approach we recommend in this book, the development team members could have some very positive influence on what user stories should be built first, rather than passively attending the meeting as some used to in the past.

Number of hours estimated to be needed for a team to finish any unfinished task during a Sprint.

Meeting during which the Scrum team will go through what worked and what did not work during the Sprint they just finished and determine whether there is anything they can learn from their experience that will make the process even better for the next Sprint.

Scrum specialist whose responsibility it is to help the rest of the team (and the organization) understand and properly apply Scrum to a project.

Generic name that covers the ScrumMaster, the product owner, and the (development) team.

A time-boxed cycle, or iteration, during which the development team is supposed to turn some selected requirements (user stories) into a potentially shippable product increment.

List of all the tasks the development team has to do during a Sprint.

A two-phase meeting: during the first part, the product owner lets the team know which requirements she thinks should be part of the Sprint, and during the second part, the team decides how to turn the selected requirements into an increment of potentially shippable product.

Meeting during which the team provides a demonstration of what they have built to the product owner and the stakeholders.

A concept in Agile and Scrum, which dictates that the development team should be responsible for organizing itself as the members see fit to get the job done. If the team does not deliver, self-organization does not mean that the ScrumMaster or product owner could not or should not intervene, in a subtle way and indirectly, to help the team move forward.

The goal that the product owner will give to the team for their Sprint, such as “laying down the foundation for US credit cards.”

Wrong adaptation of Scrum, often equated to an excuse to hide the organization’s weaknesses.

Good adaptation of Scrum that helps get the team moving forward despite some constraints they have to deal with in the real world.

A quick assessment at the beginning of a Scrum project that serves to assess the team’s ability to deliver on their results using Scrum. Knowing where the team stands with the assessment allows the team to know what they should do in order to improve their chance of using Scrum with success.

A leadership philosophy which considers that the leader or manager can be more successful and effective in helping the team by removing impediments rather than ordering them around as in the old command and control style.

Simple technique known to be very effective in helping management and teams identify goals that they can achieve within a reasonable amount of time and with available resources. SMART stands for Measurable, Achievable, Realistic, and Time-Based.

A generic name to indicate any person or team that has a stake in the Scrum project team’s success.

Index card used to describe a user story, both in agile and lean processes.

Whiteboard where team tasks and assignments are recorded in all transparency.

Production system considered to be the leanest and most effective in the world.

Qualities that help someone be a good leader. Being honest, open, authentic, available, and caring are some examples of these qualities.

Requirements estimate made before taking into account the weight of the surrounding environment.

Roles played by different users during the course of the project. Sometimes one person can play more than one role; for instance, one person can be both a system administrator and a billing approver.

Generic name used in agile software development to indicate user business requirements.

Number of user stories (usually measured in points) the development team can deliver during a Sprint.

Visual technique based on the tree and forest hierarchy that can simplify the effort put into gathering user requirements for complex projects.

A sequential software development process that makes the assumption that all the requirements should be gathered first, then analyzed, then developed, and only then tested for user sign-off before being put into production for use.