From Amachu
Jump to: navigation, search

The first references in the literature to the term 'Scrum' point to the article of Takeuchi and Nonaka in which an adaptive, quick, self-organizing product development process originating from Japan is presented. The term 'scrum' originally derives from a strategy in the game of rugby where it denotes "getting an out-of play ball back into the game" with teamwork.

The Scrum approach has been developed for managing the systems development process. It is an empirical approach applying the ideas of industrial process control theory to systems development resulting in an approach that reintroduces the ideas of flexibility, adaptability and productivity. It does not define any specific software development techniques for the implementation phase. Scrum concentrates on how the team members should function in order to produce the system flexibly in a constantly changing environment.

The main idea of Scrum is that systems development involves several environmental and technical variables (e.g. requirements, time frame, resources, and technology) that are likely to change during the process. This makes the development process unpredictable and complex, requiring flexibility of the systems development process for it to be able to respond to the changes. As a result of the development process, a system is produced which is useful when delivered.

Scrum helps to improve the existing engineering practices (e.g. testing practices) in an organization, for it involves frequent management activities aiming at consistently identifying any deficiencies or impediments in the development process as well as the practices that are used.



Scrum process includes three phases: pre-game, development and post-game

Scrum Process

In the following, the Scrum phases are introduced according to Schwaber.

The pre-game phase includes two sub-phases: Planning and Architecture/High level design.

Planning includes the definition of the system being developed. A Product Backlog list is created containing all the requirements that are currently known. The requirements can originate from the customer, sales and marketing division, customer support or software developers. The requirements are prioritized and the effort needed for their implementation is estimated. The product Backlog list is constantly updated with new and more detailed items, as well as with more accurate estimations and new priority orders. Planning also includes the definition of the project team, tools and other resources, risk assessment and controlling issues, training needs and verification management approval. At every iteration, the updated product Backlog is reviewed by the Scrum Team(s) so as to gain their commitment for the next iteration.

In the architecture phase, the high level design of the system including the architecture is planned based on the current items in the Product Backlog. In case of an enhancement to an existing system, the changes needed for implementing the Backlog items are identified along with the problems they may cause. A design review meeting is held to go over the proposals for the implementation and decisions are made on the basis of this review. In addition, preliminary plans for the contents of releases are prepared.

The development phase (also called the game phase) is the agile part of the Scrum approach. This phase is treated as a "black box" where the unpredictable is expected. The different environmental and technical variables (such as time frame, quality, requirements, resources, implementation technologies and tools, and even development methods) identified in Scrum, which may change during the process, are observed and controlled through various Scrum practices during the Sprints (see the section below) of the development phase. Rather than taking these matters into consideration only at the beginning of the software development project, Scrum aims at controlling them constantly in order to be able to flexibly adapt to the changes.

In the development phase the system is developed in Sprints. Sprints are iterative cycles where the functionality is developed or enhanced to produce new increments. Each Sprint includes the traditional phases of software development: requirements, analysis, design, evolution and delivery phases. The architecture and the design of the system evolve during the Sprint development. One Sprint is planned to last from one week to one month. There may be, for example, three to eight Sprints in one systems development process before the system is ready for distribution. Also there may be more than one team building the increment.

The post-game phase contains the closure of the release. This phase is entered when an agreement has been made that the environmental variables such as the requirements are completed. In this case, no more items and issues can be found nor can any new ones be invented. The system is now ready for the release and the preparation for this is done during the post-game phase, including the tasks such as the integration, system testing and documentation.

Roles and responsibilities

There are six identifiable roles in Scrum that have different tasks and purposes during the process and its practices: Scrum Master, Product Owner, Scrum Team, Customer, User and Management. In the following, these roles are presented according to the definitions of Schwaber and Beedle.

Scrum Master

Scrum Master is a new management role introduced by Scrum. Scrum Master is responsible for ensuring that the project is carried through according to the practices, values and rules of Scrum and that it progresses as planned. Scrum Master interacts with the project team as well as with the customer and the management during the project. He is also responsible for ensuring that any impediments are removed and changed in the process to keep the team working as productively as possible.

Product Owner

Product Owner is officially responsible for the project, managing, controlling and making visible the Product Backlog list. He is selected by the Scrum Master, the customer and the management. He makes the final decisions of the tasks related to product Backlog, participates in estimating the development effort for Backlog items and turns the issues in the Backlog into features to be developed.

Scrum Team

Scrum Team is the project team that has the authority to decide on the necessary actions and to organize itself in order to achieve the goals of each Sprint. The scrum team is involved, for example, in effort estimation, creating the Sprint Backlog, reviewing the product Backlog list and suggesting impediments that need to be removed from the project.


Customer participates in the tasks related to product Backlog items for the system being developed or enhanced.


Management is in charge of final decision making, along with the charters, standards and conventions to be followed in the project. Management also participates in the setting of goals and requirements. For example, the management is involved in selecting the Product Owner, gauging the progress and reducing the Backlog with Scrum Master.


Scrum does not require or provide any specific software development methods/practices to be used. Instead, it requires certain management practices and tools in the various phases of Scrum to avoid the chaos caused by unpredictability and complexity.

In the following, the description of Scrum practices is given based on Schwaber and Beedle.

Product Backlog

Product Backlog defines everything that is needed in the final product based on current knowledge. Thus, Product Backlog defines the work to be done in the project. It comprises a prioritized and constantly updated list of business and technical requirements for the system being built or enhanced. Backlog items can include, for example, features, functions, bug fixes, defects, requested enhancements and technology upgrades. Also issues requiring solution before other Backlog items can be done are included in the list. Multiple actors can participate in generating Product Backlog items, such as customer, project team, marketing and sales, management and customer support.

This practice includes the tasks for creating the Product Backlog list, and controlling it consistently during the process by adding, removing, specifying, updating, and prioritizing Product Backlog items. The Product Owner is responsible for maintaining the Product Backlog.

Effort estimation

Effort estimation is an iterative process, in which the Backlog item estimates are focused on a more accurate level when more information is available on a certain Product Backlog item. The Product Owner together with the Scrum Team(s) are responsible for performing the effort estimation.


Sprint is the procedure of adapting to the changing environmental variables (requirements, time, resources, knowledge, technology etc.). The Scrum Team organizes itself to produce a new executable product increment in a Sprint that lasts approximately thirty calendar days. The working tools of the team are Sprint Planning Meetings, Sprint Backlog and Daily Scrum meetings (see below). The Sprint with its practices and inputs is illustrated in Figure.

Practices and Inputs of Sprint

Sprint Planning meeting

A Sprint Planning Meeting is a two-phase meeting organized by the Scrum Master. The customers, users, management, Product Owner and Scrum Team participate in the first phase of the meeting to decide upon the goals and the functionality of the next Sprint (see Sprint Backlog below). The second phase of the meeting is held by the Scrum Master and the Scrum Team focusing on how the product increment is implemented during the Sprint.

Sprint Backlog

Sprint Backlog is the starting point for each Sprint. It is a list of Product Backlog items selected to be implemented in the next Sprint. The items are selected by the Scrum Team together with the Scrum Master and the Product Owner in the Sprint Planning meeting, on the basis of the prioritized items and goals set for the Sprint. Unlike the Product Backlog, the Sprint Backlog is stable until the Sprint (i.e. 30 days) is completed. When all the items in the Sprint Backlog are completed, a new iteration of the system is delivered.

Daily Scrum meeting

Daily Scrum meetings are organized to keep track of the progress of the Scrum Team continuously and they also serve as planning meetings: what has been done since the last meeting and what is to be done before the next one. Also problems and other variable matters are discussed and controlled in this short (approximately 15 minutes) meeting held daily. Any deficiencies or impediments in the systems development process or engineering practices are looked for, identified and removed to improve the process. The Scrum Master conducts the Scrum meetings. Besides the Scrum team also the management, for example, can participate in the meeting.

Sprint Review meeting

On the last day of the Sprint, the Scrum Team and the Scrum Master present the results (i.e. working product increment) of the Sprint to the management, customers, users and the Product Owner in an informal meeting. The participants assess the product increment and make the decision about the following activities. The review meeting may bring out new Backlog items and even change the direction of the system being built.

Personal tools