The Agile Dictionary

A lightweight framework to help people, teams, and complex organizations develop value through adaptive solutions for complex problems. Scrum is the most widely recognized Agile framework and is compatible with other agile practices like Extreme Programming and test-driven development.

Scrum is comprised of a series of short iterations–called sprints–each of which ends with the delivery of an increment of business value. A simple way to remember all the key elements of Scrum is this; “3” roles, “5” events, and “3” artifacts. The 3 roles are: Product Owner, Developers, and Scrum Master. Scrum counts on a Scrum Master to foster an environment where: Product Owners sequence complex problems into a backlog, Developers work on sequenced product backlog items and deliver business value after a sprint, and Developers and Stakeholders take note of their delivery approach during a sprint and look to make improvements for the following sprint. The 5 events that are time-boxed: sprint planning, daily scrum, sprint, sprint review, and sprint retrospective. The 3 artifacts are: product backlog (product goal), sprint backlog (sprint goal), and the product increment (definition of done).

Scrum is deliberately incomplete. Rather than provide people with precise instructions, the rules of Scrum help guide their relationship and interactions. Scrum is not a process, technique, or a definitive method. Scrum is simply a framework and within the framework we may apply various process and or techniques.

Tip: You will sometimes hear the term scrum used interchangeably with the term agile, but this is incorrect. Agile is not a framework, but a broader set of values and practices, while scrum is a specific framework that fits comfortably under the agile umbrella.

Background Of The Term

The term “scrum,” as it is commonly applied to software development, began its life as a sports metaphor. The term “scrum” derives from the game of rugby, where it refers to a team that moves down the field as one body.  Scrum was first introduced as a metaphor for industrial processes in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka, two Japanese academics who used it to describe a new, flexible approach in a paper titled “The New New Product Development Game.”

In the early 90’s, several complimentary events conspired to bring the term “scrum” into use within agile development community. In 1990 Peter DeGrace and Leslie Hulet Stahl published a book called “Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms,” which contained a blistering critique of the commonly accepted “waterfall” method for software development. DeGrace and Hulet Stahl quoted Takeuchi and Nonaka’s paper as a possible remedy.  Influenced by this popular work, a team of software developers, Jeff Sutherland, John Scumniotales, and Jeff McKenna, used the term scrum to describe a new framework they had begun to develop in accordance with the values and principles of the Agile Manifesto. In parallel, Ken Schwaber was developing a similar framework at his company, Advanced Development Methods.

The two teams were aware of each other’s work, and in 1995, Schwaber and Sutherland jointly authored a paper that laid out the basics of a framework they dubbed scrum. Schwaber later collaborated with Mike Beedle on the book Agile Software Development with Scrum. Schwaber went on to found the Scrum Alliance, which is now the certifying body for scrum trainers and practitioners of all levels, and the primary source of authoritative information on the state of scrum as practiced today.

Further Learning

The Scrum Guide – by Ken Schwaber & Jeff Sutherland

Scrum Overview – by Scrum Alliance

Intro to the Scrum Framework – by Scrum Inc.

Scrum’s artifacts are listed in the 2020 Scrum Guide. They represent the work the team does and the business value of the product.

Each artifact contains a commitment with enough information that the commitment can be measured. The commitments are:

• For the Product Backlog, it is the Product Goal.
• For the Sprint Backlog, it is the Sprint Goal.
• For the Increment, it is the Definition of Done.

These commitments reinforce the philosophy that agile goals develop from team experience and history.

See Task Board.

See Iteration.

A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.

Background of the Term

The term spike comes from Extreme Programming (XP), where “A spike solution is a very simple program to explore potential solutions.” XP guru Ward Cunningham describes how the term was coined on the C2.com wiki: “I would often ask Kent [Beck], ‘What is the simplest thing we can program that will convince us we are on the right track?’ Such stepping outside the difficulties at hand often led us to simpler and more compelling solutions. Kent dubbed this a Spike. I found the practice particularly useful while maintaining large frameworks.”

Further Learning

What’s a Spike, Who should enter it, and how to word it? by Andrew Fuqua

Also: Iteration.

The uninterrupted period of time during which a Scrum development team performs work. This segment of time is most commonly time boxed for two weeks but can be shorter. At the end of this segment of work the team delivers “potentially shippable” product in the form of either improvement upon existing functionality, or an increment or increments of new functionality. This deliverable can be a new feature or feature set, or the improvement or expansion of an existing feature that was completed in an earlier iteration. In Scrum, sprints begin with a planning meeting, and end with a retrospective.

In SAFe, the sprint is referred to as an iteration. Extreme Programming refers to sprints as “small releases,” using this term interchangeably with the term iteration. Dynamic Systems Development Method (DSDM) refers to the sprint as a timebox.

See Backlog.

The sprint goal is the commitment associated with the sprint backlog. The sprint backlog is one of the scrum artifacts listed in the 2020 Scrum Guide.

The developers review the backlog and priorities and commit to the sprint goal during sprint planning. It is the single objective for the sprint. The goal allows the developers to focus on the desired outcome of the sprint and gives them the flexibility on how to achieve it. In addition, it encourages the scrum team to work together rather than on separate initiatives.

The sprint goal is added to the sprint backlog. During the sprint, the developers keep the sprint goal in mind. If during the sprint they find that requirements have to change to meet the goal, they bring the concerns to the product owner to review and negotiate the scope of the sprint backlog within the sprint without affecting the sprint goal.

Further Learning

The retrospective is a time-boxed meeting held at the end of a sprint or iteration. The team examines its processes to determine what succeeded and what can be improved. The retrospective is key to an agile team’s ability to “inspect and adapt” in the pursuit of “continuous improvement.”

The meeting’s goal is to have a positive outcome and identify one or two impactful items that will increase quality and effectiveness. The team then creates a plan to implement them in the next sprint. The emphasis is on actionable items, not a comprehensive analysis.

The agile retrospective differs from other methodologies such as “Lessons Learned” exercises, which usually aim to generate a list of what went wrong.

Retrospective facilitation is a distinct skill set. Retrospectives may take many forms, but there is usually a facilitator who may or may not be a team member. The process is generally broken down into three phases: data gathering, data analysis, and action items. Formal tools and exercises can be used to gather and analyze the team’s data. The team often has fun during the retrospective and utilizes different tolls and games to gather the data. The resource list below lists some suggestions for tools and games that can be used during the meeting.

Background Of The Term

The term retrospective was first applied to this meeting by Norman Kerth, who describes its origins in his 2001 book Project Retrospectives: A Handbook for Team Reviews: “Wayne and Eileen Strider, two fellow facilitators, suggested that we call what we do a retrospective. The word seemed appropriate; it didn’t carry any loaded meanings and could be applied to projects without the implication of success or failure.”

Further Learning

Agile Retrospectives: Making Good Teams Great – Book by Esther Derby and Diana Larson
Dixit Sprint Retrospective Game – Agile Learning Labs Blog
Agile Retrospective Resource Wiki – Agile Retrospectives Organization Site
Agile Retrospectives Done Right – Atlassian Agile Coach – YouTube – 5 Minutes

Also: Iteration Review, Demo

The sprint review is a scrum event held at the end of an iteration at which the scrum team demonstrates working software or product and solicits feedback from customers, management, other development teams, and other project stakeholders. Although sometimes referred to as a “demo”, the sprint review is much more than that. It includes a collaborative discussion of what to do next, so the meeting is both backward-reviewing as well as forward-facing.

Mike Cohn describes the format of a sprint review in his introduction to scrum:

“The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.”^[1]

In scrum the meeting is timeboxed, for example, to no more than two hours for a two-week sprint.

[1] Sprint Review Meeting

Further Learning

What is a Sprint Review? – Scrum.org
Making the Most of the Sprint Review – Scrum.org – Mary Iqbal
How to improve your Scrum Sprint Reviews – GroetenUitDelft – video, five minutes