Scrum

Scrum - A Description

Scrum is a framework for accomplishing work. It is not a "defined process for accomplishing work". Instead, Scrum is founded on the principle that bringing people together to self-organize within a loosely-structured way of working will enable them to observe what is happening and to improve it. Reading a description of Scrum is not sufficient to understand it: reading many descriptions will aid in understanding. To really understand Scrum, or any Agile approach, you must adopt it, live inside it, and think about it continually and deeply.

This is one description of Scrum. There are many descriptions on this site, and elsewhere. Read as many as you can, and remember:

Scrum is not something you read about. It is something you do.

Principles

Scrum is the best-known of the "Agile" methods. All these methods rely on similar principles, including

Scrum-specific principles, in no way contradictory to these, include

In particular, Scrum requires every Team to produce a potentially releasable increment of product in every Sprint. We will return to this point.

Quick Glossary

These terms will be used, and sometimes further defined below, and are introduced briefly here to provide context.

Scrum Structure

The people on a Scrum project consist of the Product Owner, the ScrumMaster, and the Team. The team members self organize to accomplish the work. The Product Owner selects and explains the work to be done, with the help of the team. The ScrumMaster helps the team work within the Scrum framework and the team's own selected way of working.

Product Owner

The Product Owner is the single individual who is solely responsible for drawing out the most valuable possible product by the desired date. This is done by managing the flow of work into the team, by selecting and refining items from the Product Backlog. The Product Owner maintains the backlog and ensures that everyone knows what is on it and what the priorities are. The Product Owner may be supported by other individuals but must be a single person.

Team

In Scrum, the product is developed by a cross-functional group of Team members, often called "The Dev Team", or "developers". The Team members must include all the skills necessary to produce a potentially releasable product increment in the next Sprint (typically two weeks). When Team members are able to work on multiple aspects of the development, they become much more valuable to the project.

At the end of every Sprint, the Team must deliver a working, potentially releasable, product increment. This increment may be too small to ship, but it must be good enough to ship. The Team operates according to a "Definition of Done" which is agreed upon between the developers and the Product Owner. 

The Team is responsible for how the work is done, ensuring delivery of value to the Product Owner. In particular, this includes a responsibility for all aspects of product quality. In addition, the Team works actively with the Product Owner to help specify the product and to ensure that the Product Owner is apprised of all important technical concerns.

The team members self-organize to determine how the work is to be done.

ScrumMaster

The ScrumMaster helps and advises the whole team on how to self-organize to get the work done, according to the agreed Definition of Done, the Scrum principles, and the team's own values and rules. This is a coaching / leadership position. It is emphatically not a management position: the whole team is self-organizing, as are the developer Team. The ScrumMaster helps the Product Owner, ensures that impediments are removed, and may have a communication responsibility to the rest of the enterprise. Even so, ScrumMaster is not a management position in Scrum.

Stakeholders

There are of course many individuals in the organization and elsewhere who have a  strong interest in the product. These are often referred to as "stakeholders". They are not a formal role in Scrum, but they are people whom the project serves, and who need to be listened to and kept informed.

Other Roles

These three roles make up Scrum. There are no other roles in Scrum. Product Owner, ScrumMaster, Team. That's it.

The Sprint

The Sprint is the fixed period of time, typically two weeks though up to a month is permissible, in which the developers produce a new increment of potentially releasable software. The Sprint period is expected to be consistent throughout the project. It is not uncommon to step down to a shorter period as a team's abilities increase. Each Sprint has a Sprint Goal, which summarizes what is intended to be accomplished by the work of the Sprint.

Scrum Meetings and Activities

Scrum specifies four meetings and one activity as part of each Sprint: Sprint Planning, Sprint Review, Sprint Retrospective, and Daily Scrum meetings, and the Backlog Refinement activity.

Backlog Refinement

In this activity, the Product Owner, aided by the rest of the whole team and other stakeholders as needed, adds new items to the backlog, removes items that are no longer relevant, and prepares items for upcoming Sprints. They select a Backlog item, which may be rather large and vague, and break it down into one or more smaller, more focused items. Then they refine its meaning and determine acceptance criteria. Backlog refinement, in preparation for the upcoming Sprint Planning, is part of the current Sprint's effort, though it is not listed on the Sprint Backlog as a specific item. Best results are obtained when the whole team is well represented in backlog refinement rather than leaving it to the Product Owner alone.

Sprint Planning

The Sprint Planning meeting is a time-boxed meeting to decide what work will be undertaken in the next Sprint.  The Product Owner describes the Product Backlog items that are proposed for the upcoming Sprint, and the developers select the items they forecast they can complete. Then the developers self-organize to plan and do the actual work. The Sprint Planning meeting is time-boxed to about a half day, preferably less, for a two-week Sprint.

Daily Scrum

Every day there is a brief meeting of less than fifteen minutes, in which the Team tell each other what they accomplished yesterday, what they plan to accomplish today, and what is standing in their way. The team uses this meeting to ensure that they are on track for attaining the Sprint Goal.

Sprint Review

At the end of the Sprint, the whole team demonstrates what has been accomplished and discusses how things went. The meeting is informal, often includes stakeholders, and is time boxed to about two hours for a two week Sprint. The intention is to get everyone on the same page about accomplishments, needs, and opportunities for the next Sprint. Often ideas for future Sprints emerge during this meeting.

Sprint Retrospective

The whole team inspects what has happened in the current Sprint, and what has been happening in past Sprints. They determine what actions they wish to take within the Scrum framework to make things go better next time. The Sprint Retrospective usually follows directly on the heels of the Sprint Review. In any case, inspecting and adapting is part of the effort of the current Sprint, and each Sprint.

Products, Results, other Displays

Product Increment

The primary result of each Sprint is a potentially releasable product increment. On a software project every Sprint must produce real working software, implementing Backlog Items chosen by the Product Owner, and agreed to by the developers. This software must be complete according to the agreed standards of completion, the "Definition of Done". In essence this means that this software requires no more work in order to be deployed to customers should the Product Owner so desire. On a project producing something other than software, the same principle applies.

Sprint Backlog

The Sprint Backlog is the list of Product Backlog items, initially ordered by the Product Owner, selected and agreed to by the Team, for implementation in the Sprint. Sprint Backlog items are defined in sufficient detail at the time of Sprint Planning to allow the team to be sure enough of what they entail to commit to doing them. The Sprint Backlog is the sole source of work to be done during the Sprint. This means that all features, bug fixes, emergency support actions -- everything the team does -- comes through the Sprint Backlog.

Product Backlog

The Product Backlog is an ordered list of all the things that might be required to be part of the product. It is the single source from which all requirements flow. This means that all work the team does comes from the Product Backlog. All feature ideas, enhancements, bug fixes, documentation requirements -- everything the team does -- comes from the Product Backlog.

Progress Monitors

The Team, Product Owner, and stakeholders can see the work done, and the work remaining to be done, at any time. This holds for the product as a whole, and for the work of the current Sprint. Various approaches are used for displaying this information: "burn" charts, story and task boards, spreadsheets, and so on. The information can be used either to project when a given selection of features will be done, or to choose which features to do so as to ship the product on a chosen date. The most important progress monitor for a Scrum project is the Product Increment.

Scrum Summary

Scrum is a simple framework, embodying these few roles, meetings, activities, and information displays. Scrum is a framework for success. Success comes when the whole team works together, inspecting progress and adapting their specific process within the Scrum framework. Scrum is a place to begin. Your objective is not to do Scrum; it is to succeed using Scrum as a basis for observing your project and improving it.