Scrum Principles

Empirical Process Control emphasizes the core philosophy of Scrum based on the three main ideas which are as follows: Transparency, Inspection, and Adaptation. Empirical process control aids learning through experimentation when the problem is not well-defined or when there are no clear solutions.

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum, transparency is depicted through the following:

• A Project Vision Statement which can be viewed by all business stakeholders and the Scrum Team
• An open Prioritized Product Backlog with prioritized User Stories that can be viewed by everyone, both within and outside the Scrum Team
• A Sprint Backlog which is the subset of the Prioritized Product Backlog and contains the Product Backlog Items selected for the Sprint by the Scrum Team
• A Release Planning Schedule which may be coordinated across multiple Scrum Teams and other business stakeholders
• Clear visibility into the team’s progress using a Scrumboard, Burndown Chart, and other information radiators
• Daily Standup Meetings are conducted during the Conduct Daily Standup process, in which all team members report what they have done the previous day, what they plan to do today, and any problems preventing them from completing their tasks in the current Sprint
• Sprint Review Meetings are conducted during the Demonstrate and Validate Sprint process, in which the Scrum Team demonstrates the potentially shippable Sprint Deliverables to the Product Owner and Business Stakeholders

                                    The figure summarizes the concept of transparency in Scrum

Inspection allows all facets of any Scrum process to be inspected by anyone. This inspection could be to do with products, processes, or any other activity in a Scrum project. Inspection in Scrum is depicted through the following:

• Use of a common Scrumboard and other information radiators which show the progress of the Scrum Team on completing the tasks in the current Sprint.
• Collection of feedback from the customer and other business stakeholders during the Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning processes.
• Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process.

                                                   The figure summarizes Inspection in Scrum

Adaptation happens as the Scrum Core Team and Business stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. Some examples of opportunities for adaptation in a Scrum Framework include:

• In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. More experienced members of the Scrum Team also mentor those with relatively less experience in knowledge of the project or technology.
• Risk identification is performed and iterated throughout the project. Identified risks become inputs to several Scrum processes including Create Prioritized Product Backlog, Refine Prioritized Product Backlog, and Demonstrate and Validate Sprint.
• Improvements can also result in Change Requests, which are discussed and approved during the Develop Epic(s), Create Prioritized Product Backlog, and Refine Prioritized Product Backlog processes.
• The Scrum Guidance Body interacts with Scrum Team members during the Create User Stories, Estimate Tasks, Create Deliverables, and Refine Prioritized Product Backlog processes to offer guidance and also provide expertise as required.
• In the Retrospect Sprint process, Agreed Actionable Improvements are determined based on the outputs from the Demonstrate and Validate Sprint process.
• In Retrospect Release Meetings, participants document lessons learned and perform reviews looking for opportunities to improve processes and address inefficiencies.

The figure summarizes the concept of Adaptation in Scrum

Scrum believes that employees are self-motivated and seek to accept greater responsibility. So, they deliver much greater value when self-organized. The preferred leadership style in Scrum is “collaborative leadership”, which emphasizes achieving results by focusing on the needs of the Scrum Team.

Self-organization does not mean that team members are allowed to act in any manner that they want to. It just means that once the Project Vision is defined in the Create Project Vision process, the Product Owner, Scrum Master, and Development Team get identified. Also, the Scrum Core Team itself works very closely with relevant Stakeholders for refining requirements better as they go through the Develop Epic(s) and Create User Stories process. Team expertise is used to assess the inputs needed to execute the planned work of the project. This judgment and expertise are applied to all technical and management aspects of the project during the Create Deliverables process.

Although prioritization is primarily done by the Product Owner who represents the Voice of Customer, the self-organized Scrum Team is involved in task breakdown and estimation during the Identify Tasks and Estimate Tasks processes. During these processes, each team member is responsible for determining what work he or she will be doing. The Scrum Team also helps the Product Owner by identifying risks and dependencies.  During the execution of a Sprint, if team members need any help with completing their tasks, Scrum addresses this through the regular interaction mandatory with the Daily Standup Meetings. The Scrum Team itself interacts with other teams through the Scrum of Scrums (SoS) Meetings and can look for additional guidance as required from the Scrum Guidance Body.

Finally, the Scrum Team and Scrum Master work closely to demonstrate the product increment created during the Sprint in the Demonstrate and Validate Sprint process where properly completed deliverables are accepted. Since the Deliverables are potentially shippable, (and the Prioritized Product Backlog is prioritized by User Stories in the order of value created by them), the Product Owner and the customer can clearly visualize and articulate the value being created after every Sprint; and Scrum Teams, in turn, have the satisfaction of seeing their hard work being accepted by the customer and other business stakeholders.

Self-organization as an essential principle in Scrum leads to the following:

• Team buy-in and shared ownership
• Motivation, which leads to an enhanced performance level of the team
• An innovative and creative environment conducive to growth
• Selection of the simplest and best approach to satisfy given requirements

The chief goals of self-organizing teams are as follows.

• Understand the Project Vision and why the project delivers value to the organization
• Estimate User Stories during the Estimate User Stories process and assign tasks to themselves during the Update Sprint Backlog process
• Identify tasks independently during the Identify Tasks process
• Apply and leverage their expertise from being a cross-functional team to work on the tasks during the Create Deliverables process
• Deliver tangible results which are accepted by the customer and other business stakeholders during the Demonstrate and Validate Sprint process
• Resolve individual problems together by addressing them during Daily Standup Meetings
• Clarify any discrepancies or doubts and be open to learning new things
• Upgrade knowledge and skill on a continuous basis through regular interactions within the team
• Maintain the stability of team members throughout the duration of the project by not changing members, unless unavoidable

The figure summarizes the goals of a Self-Organizing Team

Collaboration in Scrum refers to the Scrum Core Team working together and interfacing with the business stakeholders to create and validate the deliverables of the project to meet the goals outlined in the Project Vision. It is important to note the difference between cooperation and collaboration here. Cooperation occurs when the work product consists of the sum of the work efforts of various people on a team. Collaboration occurs when a team works together to play off each other’s inputs to produce something greater. In order to achieve full collaboration, it is important to establish trust between all team members.

The core dimensions of collaborative work are as follows:

• Awareness—Individuals working together need to be aware of each other’s work.
• Articulation—Collaborating individuals must partition work into units, divide the units among team members, and then after the work is done, reintegrate it.
• Appropriation—Adapting technology to one’s own situation; the technology may be used in a manner completely different than expected by the designers.

The Agile Manifesto (Fowler & Highsmith, 2001) stresses “customer collaboration over contract negotiation.” Thus, the Scrum framework adopts an approach in which the Scrum Core Team members (Product Owner, Scrum Master, and Development Team), collaborate with each other and the business stakeholders to create the deliverables that provide the greatest possible value to the customer. This collaboration occurs throughout the project.

Collaboration ensures that the following project benefits are realized:

• The need for changes due to poorly clarified requirements is minimized
• Risks are identified and dealt with efficiently
• The true potential of the team is realized
• Continuous improvement is ensured through lessons learned

Collaboration occurs when a team works together to play off each other’s inputs to produce something greater. Whereas Cooperation occurs when the work product consists of the sum of the work efforts of various people on a team.

For many of the Scrum practices, high-bandwidth communication is required. To enable this, it is preferred that team members are colocated. Colocation allows both formal and informal interaction between team members. This provides the advantage of having team members always at hand for coordination, problem-solving, and learning. Some of the benefits of colocation are the following:

• Questions get answered quickly.
• Problems are fixed on the spot.
• Less friction occurs between interactions.
• Trust is gained and awarded much more quickly.

Although collocated teams are preferred, at times the Scrum Team may be distributed (i.e., teams working in different physical locations). Several members of a Scrum team could be working from multiple locations (even different countries), or even working from home. Even if there are collocated teams, they should be prepared to always have the flexibility to work from home or to work remotely because of extenuating circumstances. In such situations, it may be required to ensure that Scrum works in distributed teams. With the prevailing situation globally, most teams are now working remotely. Thus, it becomes even more important for Scrum Master to facilitate the process. The teams can use web-conferencing tools, online meeting platforms, etc. to easily collaborate from anywhere across the globe.

The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. One of the most effective tools for delivering the greatest value in the shortest amount of time is prioritization.

Prioritization can be defined as the determination of the order and separation of what must be done now, from what needs to be done later. The concept of prioritization is not new to project management. The traditional Waterfall model of project management proposes using multiple task prioritization tools. From the Project Manager’s point of view, prioritization is integral because certain tasks must be accomplished first to expedite the development process and achieve the project goals. Some of the traditional techniques of task prioritization include setting deadlines for delegated tasks and using prioritization matrices.

Scrum, however, uses Value-based Prioritization as one of the core principles that drive the structure and functionality of the entire Scrum framework—it helps projects benefit through adaptability and iterative development of the product or service. More significantly, Scrum aims at delivering a valuable product or service to the customer on an early and continuous basis. Prioritization is done by the Product Owner when he or she prioritizes User Stories in the Prioritized Product Backlog. The Prioritized Product Backlog contains a list of all the requirements needed to bring the project to fruition.

Once the Product Owner receives the business requirements from the customer, the business requirements are written in the form of Epics and User Stories(a specific format for capturing requirements). The Product Owner works with the customer and other business stakeholders to determine which business requirements provide maximum business value. Sometimes, a customer may mandate all User Stories to be of high priority. While this might be true, even a list of high-priority User Stories needs to be prioritized within the list itself. The Product Owner must understand what the customer wants and values in order to arrange the User Stories into a list from highest to lowest priority. This list is called the Prioritized Product Backlog and should contain all the requirements for the project. Prioritizing a backlog involves determining the criticality of each User Story. High-value requirements are identified and moved to the top of the Prioritized Product Backlog. The processes in which the principle of Value-based Prioritization is put into practice are Create Prioritized Product Backlog and Refine Prioritized Product Backlog.

Simultaneously, the Product Owner must work with the Scrum Team to understand the project risks and uncertainty as they may have negative consequences associated with them. This should be taken into account while prioritizing User Stories on a value-based approach (refer to the Risk chapter for more information). The Scrum Team also alerts the Product Owner of any dependencies that arise out of implementation. These dependencies must be taken into account during prioritization. Prioritization may be based on a subjective estimate of the projected business value or profitability, or it can be based on results and analysis of the market using tools including, but not limited to, customer interviews, surveys, financial models and analytical techniques.

The Product Owner has to translate the inputs and needs of the business stakeholders to create the Prioritized Product Backlog. Hence, while prioritizing the User Stories in the Prioritized Product Backlog, the following three factors are considered (see figure below):

• Value
• Risk or uncertainty
• Dependencies

Thus, prioritization results in deliverables that satisfy the requirements of the customer with the objective of delivering the maximum business value in the least amount of time.

                                                                 Value-based Prioritization

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

• Efficient development process
• Fewer overheads
• High velocity for teams
• Brings sharper team focus
• Ensures that team members come well-prepared

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

The different Scrum Time-boxes are as follows:

• Sprint: A Sprint is a Time-boxed iteration of one to four weeks in duration during which the Scrum Master guides, facilitates, and shields the Scrum Team from both internal and external impediments during the Create Deliverables process. This aids in avoiding vision creep that could affect the Sprint goal. During this time, the team works to convert the requirements in the Prioritized Product Backlog into shippable product functionalities. To get maximum benefits from a Scrum Project, and to provide maximum flexibility for change, the length of a Sprint should be as short as possible. At the same time, the Sprint must be long enough for the team to be able to create a working product which can be reviewed and approved by the Product Owner.
• Daily Standup Meeting: The Daily Standup Meeting is a short daily meeting, Time-boxed to 15 minutes. This meeting is carried out by the team as part of the Conduct Daily Standup process. The team members get together to report the progress of the project by answering the following three questions:
  • What have I done since the last meeting?
  • What do I plan to do before the next meeting?
  • What impediments or obstacles (if any) am I currently facing?
• Sprint Planning Meeting: This meeting is conducted prior to the Sprint as part of the Commit User Stories, Identify Tasks, Estimate Tasks, and Update Sprint Backlog processes. It is Time-boxed to eight hours for a one-month Sprint. Sprint Planning Meeting satisfies the following objectives:
  • Objective Definition—During the first part of the meeting, the Product Owner explains the highest priority User Stories or requirements in the Prioritized Product Backlog to the Scrum Team. The Scrum Team in collaboration with the Product Owner then commits to the User Stories, which define the Sprint goal.
  • Task Identification and Estimation—The Scrum Team then decides “how” to complete the selected Prioritized Product Backlog Items to fulfill the Sprint goal. The Committed User Stories and related Effort Estimated Tasks are included in the Sprint Backlog to be tracked.
• Sprint Review Meeting: The Sprint Review Meeting is Time-boxed to one hour for each week of Sprint duration. For example, for a one-month Sprint(four weeks), the Time-box for Sprint Review Meeting should be for 4 hours. During the Sprint Review Meeting that is conducted in the Demonstrate and Validate Sprint process, the Scrum Team presents the deliverables of the current Sprint to the Product Owner. The Product Owner reviews the product (or product increment) against the agreed Acceptance Criteria and either accepts or rejects the completed User Stories.
• Retrospect Sprint Meeting: The Retrospect Sprint Meeting is Time-boxed to one hour for each week of Sprint duration. For example, for a one-month Sprint (four weeks), the Time-box for Retrospect Sprint Meeting should be for 4 hours and is conducted as part of the Retrospect Sprint process. During this meeting, the Scrum Team gets together to review and reflect on the previous Sprint in terms of the processes followed, tools employed, collaboration and communication mechanisms, and other aspects relevant to the project. The team discusses what went well during the previous Sprint and what did not go well, the goal being to learn and make improvements in the Sprints to follow. Some improvement opportunities or best practices from this meeting could also be updated as part of the Scrum Guidance Body documents.

Time-Box Durations for Scrum Meetings

The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. To achieve this practically, Scrum believes in the Iterative Development of Deliverables.

In most complex projects, the customer may not be able to define very concrete requirements or is not confident of what the end product may look like. The iterative model is more flexible in ensuring that any change requested by the customer can be included as part of the project. User Stories may have to be written constantly throughout the duration of the project. In the initial stages of writing, most User Stories are high-level functionalities. These User Stories are known as Epic(s). An Epic is usually too large for teams to complete in a single Sprint. Therefore, they are broken down into smaller User Stories.

The Product Owner’s task is to ensure increased ROI by focusing on value and its continuous delivery with each Sprint. The Product Owner should have a very good understanding of the project’s business justification and the value the project is supposed to deliver as he drafts the Prioritized Product Backlog and thereby decides what deliverables and hence values are delivered in each Sprint. Then the Identify Tasks, Estimate Tasks, and Update Sprint Backlog processes produce the Sprint Backlog which the team uses to create the deliverables.

In each Sprint, the Scrum Master has to ensure that the Scrum processes are followed and facilitate the team to work in the most productive manner possible. The Scrum Team self-organizes and aims to create the Sprint Deliverables from the User Stories in the Sprint Backlog. In large projects, various cross-functional teams work in parallel across Sprints, delivering potentially shippable solutions at the end of each Sprint. After the Sprint is complete, The Product Owner accepts or rejects the deliverables based on the Acceptance Criteria.

The benefit of iterative development is that it allows for course correction as all the people involved get a better understanding of what needs to be delivered as part of the project and incorporate this learning in an iterative manner. Thus, the time and effort required to reach the final endpoint are greatly reduced and the team produces deliverables that are better suited to the final business environment.

As illustrated in the figure below, Scrum projects are completed in an iterative manner delivering value throughout the lifecycle of the project.