Agile Glossary

A construct that helps teams manage product development and other "knowledge work" through empirical process control, in that it provides a means for teams to establish a hypothesis of how they think something works, test the hypothesis, reflect on the experience, and make any appropriate adjustments. It seeks to enable a dedicated, cross-functional Scrum Team to consistently deliver value and uses a particular set of Events, Artifacts, and Roles to show progress on an iterative basis. Scrum by itself is seldom enough to ensure success over the medium to long term, and thus "Scrum teams" typically employ principles and practices associated with Lean, Kanban, and eXtreme Programming (XP), to name a few examples.

A coach, facilitator, impediment remover, and servant leader, the SM is one of the three roles on a Scrum team. The SM works with the team to establish psychological safety, ensuring they are collaborating effectively and delivering business value at a consistent, sustainable pace. The SM also acts as a change agent at the team level and beyond, seeking to identify areas of potential improvement and launching experiments to help the team and the organization continuously improve.

Teams decide for themselves who will do what work, keeping in mind the skills and abilities of team members, and the preferred ordering of completing particular work items. That is, self-organizing teams are fully empowered in terms of HOW they complete a particular body of work, where it is assumed that they understand the WHAT and the WHY of that body of work.

A view of how groups interact, based on the ways in which their relationships and other dynamics are defined. A key aspect is based on building Communities of Practice, which tend to be more durable and to demonstrate autonomous forms of interactions, driven by the interests of the group. Communities of Practice can also be incubators for discovery, innovation, and Continuous Improvement.

In Scrum, a fixed timebox (iteration) that repeats during a product development effort. Throughout a Sprint, a team focuses on completing work items, so as to deliver business value during every Sprint, such that there is a steady flow of work to Done. The work items that the team completes during the Sprint are referred to collectively as the Increment.

A set of work items that are chosen to be worked on during a particular iteration; in Scrum, an iteration is called a Sprint, and thus the set of work items a team decides to work on during that iteration are collectively referred to as the Sprint Backlog. Teams are strongly encouraged to be very selective about how many work items they include in a Sprint Backlog; that is, only include work items that they are confident they can complete. When teams start a Sprint with more work items than they can realistically complete, what happens is that the team tries to work on too many things at the same time, and as a result, has trouble finishing work by the end of the Sprint. See also Product Backlog.

In Scrum, a statement, or a set of statements, which summarize what the expected outcome(s) is/are at the end of a Sprint. Establishing a Sprint Goal or Sprint Goals helps ensure that all members of a Scrum Team have a shared understanding of what they seek to accomplish, and also acts as a summation of business value which can be more readily understood by stakeholders than the list of work items that the Scrum Team intends to complete.

In Scrum, a meeting that occurs at the beginning of an iteration (Sprint), where the Scrum Team examines the Product Backlog, and selects a set of high-priority items to work on during that Sprint. The primary outcomes from Sprint Planning include articulation of a Sprint Goal or Goals, decisions on what to work on, and decisions on what approach is to be taken to complete the selected work items.

In Scrum, a meeting that occurs at the end of an iteration (Sprint), where a team reflects on the process that it is following, celebrates things that are going well, and identifies actionable steps associated with areas of potential improvement. A Scrum Team might choose to evaluate many different aspects of its work, focusing in particular on team dynamics, and also rules and artifacts that inform how it works together, such as its Definition of Ready, Definition of Done, and Team Working Agreement. It is important to emphasize that ONLY members of a Scrum Team attend its Sprint Retrospective, to help ensure that the members of the team have psychological safety and can have an open and honest conversation.

In Scrum, a meeting that takes place at the end of an iteration (Sprint), where one or more Scrum Teams engage with stakeholders to inspect the work that was done during the Sprint, and get feedback on that work. A significant portion of the Sprint Review consists of a demonstration of working software, emphasizing what functionality has changed with the last Sprint Review. The conversation during the Sprint Review can also potentially change the nature of the work that a Scrum Team does during subsequent Sprints, based on the nature of the customer feedback.

Many teams employ abstract units to represent the difference in relative complexity and effort associated with one work item versus another. For instance, a team might have an agreement in place where a very small work item is 1 story point, a medium-sized work item is 5 story points, and a large work item is 8 story points. Teams that use story points for relative estimation often use numbers from the Fibonacci Series to represent relative size, in part because each number in the series is significantly greater or lesser than the adjacent numbers, which helps serve as an indicator that uncertainty is greater as items get larger.

Working at a pace that is reasonable over the medium to long term makes it easier to plan releases and iterations and helps avoid putting teams in a "death march." situation. Arriving at a pace that is consistently sustainable over the course of the lifespan of work on a particular product is unique to each team. As described in the original guidance on the topic, from Extreme Programming, "Demanding this team increase velocity to match that team will actually lower their velocity long term. So what ever your team's velocity is just accept it, guard it, and use it to make realistic plans."