Scrum Aspects

Organization in Scrum discusses the various facets of a Scrum project organization as well as core and non-core roles and how to form high performance Scrum Teams.

Organization, as defined in A Guide to the Scrum Body of Knowledge (SBOK® Guide), is applicable to the following:

• Portfolios, programs, and/or projects in any industry
• Products, services, or any other results to be delivered to business stakeholders
• Projects of any size or complexity

Understanding defined roles and responsibilities is very important for ensuring the successful implementation of Scrum projects.

Scrum roles fall into two broad categories:

• Core Roles—Core roles are those roles which are mandatorily required for producing the product of the project, are committed to the project, and ultimately are responsible for the success of each Sprint of the project and of the project as a whole.

• Non-core Roles—Non-core roles are those roles which are not mandatorily required for the Scrum project, and may include team members who are interested in the project, have no formal role on the project team, may interface with the team, but may not be responsible for the success of the project. The non-core roles should also be taken into account in any Scrum project.

There are three core roles in Scrum that are ultimately responsible for meeting the project objectives. The core roles are the Product Owner, Scrum Master, and Scrum Team. Together they are referred to as the Scrum Core Team. It is important to note that, of these three roles, no role has authority over the others.

1. Product Owner - The Product Owner is the person responsible for maximizing business value for the project. He or she is responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer.


2. Scrum Master - The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the product’s development successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project; clears impediments for the team; and, ensures that Scrum processes are being followed.
   
   Note that the Scrum Master role is very different from the role played by the Project Manager in a traditional Waterfall model of project management, in which the Project Manager works as a manager or leader for the project. The Scrum Master only works as a facilitator and he or she is at the same hierarchical level as anyone else in the Scrum Team—any person from the Scrum Team who learns how to facilitate Scrum projects can become the Scrum Master for a project or for a Sprint.


3. Scrum Team - The Scrum Team is a group or team of people who are responsible for understanding the business requirements specified by the Product Owner, estimating User Stories, and final creation of the project Deliverables.

The non-core roles are those roles which are not mandatorily required for the Scrum project and may not be continuously or directly involved in the Scrum process. However, knowing non-core roles is important as they could play a significant part in some Scrum projects.

Non-core roles can include the following:

• Business Stakeholder(s) - Business stakeholder(s) is a collective term that include customers, users, and sponsors, who frequently interface with the Product Owner, Scrum Master and Scrum Team to provide them with inputs and facilitate creation of the project’s product, service, or other result. Business stakeholder(s) influence the project throughout the project’s development. Business stakeholders may also have a role to play during the Develop Epic(s), Create Prioritized Product Backlog, Conduct Release Planning, Retrospect Sprint, and other important processes in Scrum. Scrum requires complete support from the business stakeholders. The responsibility for keeping business stakeholders engaged lies with the Product Owner. The following are actions recommended for maintaining stakeholder engagement and support:
  • Ensure effective collaboration and business stakeholder involvement in the project
  • Continually assess business impact
  • Maintain regular communication with business stakeholders
  • Manage business stakeholders' expectations
• Customer - The customer is the individual or the organization that acquires the project’s product, service, or other result. For any organization, depending on the project, there can be both internal customers (i.e., within the same organization) or external customers (i.e., outside of the organization).
• Users - Users are the individual or the organization that directly uses the project’s product, service, or other result. Like customers, for any organization, there can be both internal and external users. Also, in some industries customers and users may be the same.
• Sponsor - The sponsor is the individual or the organization that provides funding, support and other resources for the project. The sponsor is also the business stakeholder to whom everyone is accountable in the end. Sponsors want to understand the financial bottom line related to a product or service and are typically more concerned with final outcomes rather than with individual tasks. It is important that the sponsors who are funding the project have clarity on the following issues:
  • Benefits of implementing Scrum
  • Target deadlines and estimated costs of Scrum projects
  • Overall risks involved in Scrum projects and the steps to mitigate them
  • Expected release dates and final Deliverables
  • Supporting Services
• Vendors - Vendors include external individuals or organizations that provide products and services that are not within the core competencies of the project organization.
• Scrum Guidance Body - The Scrum Guidance Body (SGB) is an optional role but highly recommended to formalize organizational practices related to Scrum. It generally consists of a group of documents and/or a group of experts who are typically involved with defining objectives related to quality, government regulations, security, and other key organizational parameters. These objectives guide the work carried out by the Product Owner, Scrum Master, and Scrum Team. The Scrum Guidance Body also helps capture the best practices that should be used across all Scrum projects in the organization. The Scrum Guidance Body does not make decisions related to the project. Instead it acts as a consulting or guidance structure for all the hierarchy levels in the project organization—the portfolio, program, and project. Scrum Teams have the option of asking the Scrum Guidance Body for advice as required.

These could be internal and external groups that support or are impacted by the Scrum project, for example, training, logistics, marketing, finance, infrastructure etc. At times, the same person or organization can play multiple business stakeholder roles; for example, the sponsor and the customer may be the same.

The Product Owner represents the interests of the business stakeholder community to the Scrum Team. The Product Owner is responsible for ensuring clear communication of product or service functionality requirements to the Scrum Team, defining Acceptance Criteria, and ensuring those criteria are met. In other words, the Product Owner is responsible for ensuring that the Scrum Team delivers value. The Product Owner must always maintain a dual view. He or she must understand and support the needs and interests of all business stakeholders, while also understanding the needs and workings of the Scrum Team. Because the Product Owner must understand the needs and priorities of the business stakeholders, including customers and users, this role is commonly referred to as the Voice of the Customer.

As the representative of the customer and other business stakeholders, the Product Owner is said to be the Voice of the Customer as he ensures that the explicit and implicit needs of the customer are translated into User Stories in the Prioritized Product Backlog and later on used to create project Deliverables for the customer. The below table summarizes the Product Owner’s responsibilities in the various Scrum processes.

The other responsibilities of a Product Owner are:

• Determining the project's initial overall requirements and kicking off project activities; this may involve interaction with the Program Product Owner and the Portfolio Product Owner to ensure that the project aligns with direction provided by senior management
• Representing user(s) of the product or service with a thorough understanding of the user community
• Securing the initial and ongoing financial resources for the project
• Focusing on value creation and overall Return on Investment (ROI)
• Assessing the viability and ensuring the delivery of the product or service

Product owner need not always be representing an external customer or business. For example, in an IT project, non-functional requirements such as improving performance, scalability, testability, reliability, information security and compliance can also be owned by the technology groups inside the company, and Product Owners in such cases could be Technical Architects, Technical Leads etc.

The Scrum Master is the “colaborative leader” of the Scrum Team who moderates and facilitates team interactions as team coach and motivator. The Scrum Master is responsible for ensuring that the team has a productive work environment by guarding the team from external influences, removing any obstacles, and enforcing Scrum principles, aspects, and processes.

The below table summarizes the Scrum Master’s responsibilities in the various Scrum processes.

The Scrum Team is sometimes referred to as the Development Team since they are responsible for developing the product, service, or other result. It consists of a group of self-organized individuals who work on the User Stories in the Sprint Backlog to create the Deliverables for the project. The following table summarizes the Scrum Team’s responsibilities in the various processes.

Summary of responsibilities of different Scrum roles.

The below table summarizes the different Scrum roles responsibility.

Tuckman’s Model of Group Dynamics.

The Scrum approach and method may initially seem quite different and difficult for a new Scrum Team. A new Scrum Team, like any other new team, generally evolves through a four-stage process during its first Scrum project. This process is known as Tuckman’s Model of group dynamics (Tuckman, 1965). The main idea is that the four stages—Forming, Storming, Norming and Performing—are imperative for a team to develop by mitigating problems and challenges, finding solutions, planning work, and delivering results. A Scrum Master should be aware of the stage of the team, and help to become a better Performing Team. The four stages of the model are the following:

• Forming—This is often experienced as a fun stage because everything is new and the team has not yet encountered any difficulties with the project
• Storming—During this stage, the team tries to accomplish the work; however, power struggles may occur, and there is often chaos or confusion among team members
• Norming—This is when the team begins to mature, sort out their internal differences, and find solutions to work together. It is considered a period of adjustment

Performing—During this stage, the team becomes its most cohesive, and it operates at its highest level in terms of performance. The members have evolved into an efficient team of peer professionals who are consistently productive

Organizations applying the Scrum framework encourage an open environment and dialogue among employees. Conflicts among Scrum Team members are generally resolved independently, with little or no involvement from management or others outside the Scrum Team.

Conflict can be healthy when it promotes team discussions and encourages debates, as this usually results in benefits for the project and the respective team members. It is therefore important that the resolution of conflicts be encouraged, promoting an open environment where team members feel welcome to express their opinions and concerns with each other and about the project, and ultimately agree on what is to be delivered and how the work in each Sprint will be performed.

Conflict management techniques are used by team members to manage any conflicts that arise during a Scrum project. Sources of conflict evolve primarily due to schedules, priorities, resources, reporting hierarchy, technical issues, procedures, personality, and costs.

Usually there are four approaches to managing conflict in an organization applying Scrum processes:

• Win-Win - It is usually best for team members to face problems directly with a cooperative attitude and an open dialogue to work through any disagreements to reach consensus. This approach is called Win-Win. Organizations implementing Scrum should promote an environment where employees feel comfortable to openly discuss and confront problems or issues and work through them to reach Win-Win outcomes
• Lose-Win - Some team members may at times feel that their contributions are not being recognized or valued by others, or that they are not being treated equally. This may lead them to withdraw from contributing effectively to the project and agree to whatever they are being told to do, even if they are in disagreement. This approach is called Lose-Win. This situation may happen if there are members in the team (including managers) who use an authoritative or directive style of issuing orders and/or do not treat all team members equally. This approach is not a desired conflict management technique for Scrum projects, since active contribution of every member of the team is mandatory for successful completion of each Sprint. The Scrum Master should encourage the involvement of any team members who appear to be withdrawing from conflict situations. For example, it is important for all team members to speak and contribute at each Daily Standup Meeting so that any issues or impediments can be made known and managed effectively
• Lose-Lose - In conflict situations, team members may attempt to bargain or search for solutions that bring only a partial degree or temporary measure of satisfaction to the parties in a dispute. This situation could happen in Scrum Teams where team members try to negotiate for suboptimal solutions to a problem. This approach typically involves some “give and take” to satisfy every team member—instead of trying to solve the actual problem. This generally results in an overall Lose-Lose outcome for the individuals involved and consequently the project. The Scrum Team should be careful to ensure that team members do not get into a Lose-Lose mentality. Scrum Daily Standup and other Scrum meetings are conducted to ensure that actual problems get solved through mutual discussions
• Win-Lose - At times, a Scrum Master or another influential team member may believe he or she is a de facto leader or manager and try to exert their viewpoint at the expense of the viewpoints of others. This conflict management technique is often characterized by competitiveness and typically results in a Win-Lose outcome. This approach is not recommended when working on Scrum projects, because Scrum Teams are by nature self-organized and empowered, with no one person having true authority over another team member. Although the Scrum Team may include persons with different levels of experience and expertise, every member is treated equally and no person has the authority to be the primary decision maker

The preferred leadership style for Scrum projects is Collaborative Leadership. Larry Spears identifies ten traits that every effective leader should possess:

• Listening—Leaders are expected to listen intently and receptively to what is being said, or not said. They are able to get in touch with their inner voice to understand and reflect on their own feelings.
• Empathy—Good leaders accept and recognize individuals for their special and unique skills and abilities. They assume workers have good intentions and accept them as individuals, even when there are behavioral or performance issues.
• Healing—The motivation and potential to heal oneself and one’s relationship with others is a strong trait of leaders. Leaders recognize and take the opportunity to help their colleagues who are experiencing emotional pain.
• Awareness—Awareness and particularly self-awareness is a trait of leaders. This allows them to better understand and integrate issues such as those related to ethics, power, and values.
• Persuasion—Leaders use persuasion, rather than their positional authority to gain group consensus and make decisions. Rather than forcing compliance and coercion as is typical in some authoritarian management styles, leaders practice persuasion.
• Conceptualization—The ability to view and analyze problems (in an organization) from a broader conceptual and visionary perspective, rather than focusing on merely the immediate short-term goals, is a unique skill of good leaders.
• Foresight—Their intuitive minds allow leaders to use and apply past lessons and present realities to foresee the outcome of current situations and decisions.
• Stewardship—Stewardship demands a commitment to serving others. Leaders prefer persuasion over control to ensure that they gain the trust of others in the organization.
• Commitment to the growth of others—Leaders have a deep commitment to the growth of people within their organization. They take on the responsibility of nurturing the personal, professional, and spiritual growth of others (e.g., providing access to resources for personal and professional development, encouraging workers to participate in decision making).
• Building community—Leaders are interested in building communities within a working environment, particularly given the shift in societies away from smaller communities to large institutions shaping and controlling human lives.

Scrum believes that all leaders of Scrum projects (including the Scrum Master and Product Owner) should be collaborative-leaders who have the above traits.

A project is a collaborative enterprise to either create new products or services or to deliver results as defined in the Project Vision Statement. Projects are usually impacted by constraints of time, cost, scope, quality, people, and organizational capabilities. Usually, the results generated by projects are expected to create some form of business or service value.

Since value is a primary reason for any organization to move forward with a project, Value-driven Delivery must be the main focus. Delivering value is ingrained in the Scrum framework. Scrum facilitates delivery of value very early on in the project and continues to do so throughout the project lifecycle.

One of the key characteristics of any project is the uncertainty of results or outcomes. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project. Considering this uncertainty of achieving success, it is therefore important to start delivering results as early in the project as possible. This early delivery of results, and thereby value, provides an opportunity for reinvestment and proves the worth of the project to interested business stakeholders.

To provide Value-driven Delivery, it is important to:

• Understand what adds value to customers and users and to prioritize the high value requirements on the top of the Prioritized Product Backlog
• Decrease uncertainty and constantly address risks that can potentially decrease value if they materialize. Also work closely with business stakeholders showing them product increments at the end of each Sprint, enabling effective management of changes
• Create Deliverables based on the priorities determined by producing potentially shippable product increments during each Sprint so that customers start realizing value early on in the project

The responsibility of prioritizing and delivering business value in an organization for projects lies primarily with the Product Owner. For programs and portfolios, the responsibility lies with the Program Product Owner and Portfolio Product Owner, respectively. Their role is to act as effective representatives of the customer and/or sponsor. The guidelines for evaluating and measuring business value may typically be set forth by a Scrum Guidance Body.

It is important to note that although the Product Owner is primarily responsible for business justification, other persons working in Scrum projects also contribute significantly as follows:

• The sponsor provides funding for the project and constantly monitors the project to confirm realization of benefits.
• Customers and users are involved in defining the prioritized list of requirements and User Stories in the Prioritized Product Backlog, reviewing Deliverables after every Sprint or release, and confirming that benefits are realized.
• The Scrum Guidance Body may provide guidelines and recommendations related to business justification techniques and confirming benefits realization and so forth. Such guidelines and recommendations may then be referred to by Scrum Core Teams and Business Stakeholder(s).
• The Scrum Master facilitates creation of the project’s deliverables; manages risks, changes, and impediments during Conduct Daily Standup, Retrospect Sprint, and other Scrum processes. The Scrum Master coordinates with the Scrum Team to create the deliverables and with the Product Owner and other business stakeholders to ensure that benefits from the project are realized.
• The Scrum Team works on creating the deliverables of the project and contributes to realizing business value for all business stakeholders and the project. The Scrum Team is also involved in the Develop Epic(s), Create Prioritized Product Backlog, Create User Stories, Estimate User Stories, Commit User Stories, and associated processes where the business requirements are defined and prioritized. The Scrum Team also helps in identifying risks and submits Change Requests for improvements in Sprint Retrospect Meetings and other meetings.

Business justification demonstrates the reasons for undertaking a project. It answers the question “Why is this project needed?” Business justification drives all decision making related to a project. So, it is important to assess the viability and achievability of a project not only before committing to significant expenditures or investment at initial stages of the project but also to verify the business justification for continuance throughout the project’s lifecycle. A project should be terminated if it is found to be unviable; the decision should be escalated to the relevant business stakeholders and to senior management. The business justification for a project must be assessed at the beginning of the project, at pre-defined intervals throughout the project, and at any time when major issues or risks that threaten the project viability arise.

There are numerous factors a Product Owner must consider determining the business justification for a project. The following are some of the most important factors:

• Project Reasoning - Project reasoning includes all factors which necessitate the project, whether positive or negative, chosen or not (e.g., inadequate capacity to meet existing and forecasted demand, decrease in customer satisfaction, low profit, legal requirement, etc.).
• Business Needs - Business needs are those business outcomes that the project is expected to fulfill, as documented in the Project Vision Statement.
• Project Benefits - Project benefits include all measurable improvements in a product, service, or result which could be provided through successful completion of a project.
• Opportunity Cost - Opportunity cost covers the next best business option or project that was discarded in favor of the current project.
• Major Risks - Risks include any uncertain or unplanned events that may affect the viability and potential success of the project.
• Project Timescales - Timescales reflect the length or duration of a project and the time over which its benefits will be realized.
• Project Costs - Project costs are investment and other development costs for a project.

Business justification is first assessed prior to a project being initiated and is continuously verified throughout the project lifecycle. The following steps and the figure capture how business justification is determined:

• Assess and Present a Business Case
• Continuous Value Justification
• Confirm Benefits Realization

Business value should be assessed regularly to determine whether the justification or viability of executing the project continues to exist. Frequent assessment of investment in the project relative to business value being created qualifies the continued viability of a project. The expected requirements from the project may change frequently, which can impact both project investment and value creation. A key aspect of Scrum is its ability to quickly adjust to chaos created by a rapidly changing business model. In projects with ambiguous user requirements and significant potential for frequent changes, Scrum provides considerable advantages over other development models.

Monitoring the rate of delivering value is an important requirement for Scrum projects. Periodically tracking and reporting the creation of value assists in assessing project status and provides important information to the customer and other business stakeholders.

In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer.

To ensure that a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and business stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements. The Prioritized Product Backlog is simply never complete until the closure or termination of the project. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements. Since Scrum requires work to be completed in increments during Sprints, this means that errors or defects get noticed earlier through repetitive quality testing, rather than when the final product or service is near completion. Moreover, important quality-related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team—this ensures that quality is inherent in any Done deliverable created as part of a Sprint. Thus, continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and business stakeholders (including customers and users) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Scope and quality requirements for a project are determined by taking into consideration various factors such as the following:

• The business need the project will fulfill
• The capability and willingness of the organization to meet the identified business need
• The current and future needs of the target audience

The scope of a project is the total sum of all the product increments and the work required for developing the final product. Quality is the ability of the deliverables to meet the quality requirements for the product and satisfy customer needs. In Scrum, the scope and quality of the project are captured in the Prioritized Product Backlog, and the scope for each Sprint is determined by refining the large Prioritized Product Backlog Items (PBIs) into a set of small but detailed User Stories that can be planned, developed, and verified within a Sprint.

The Prioritized Product Backlog is continuously refined by the Product Owner. The Product Owner ensures that any User Stories that the Scrum Team is expected to do in a Sprint are refined prior to the start of the Sprint. In general, the most valuable requirements in solving the customers’ problems or meeting their needs are prioritized as high and the remaining are given a lower priority. Less important User Stories are developed in subsequent Sprints or can be left out altogether according to the customer’s requirements. Throughout the entire project, the Product Owner, customer, and the Scrum Team can discuss the list of features of the product to comply with the changing needs of the customers.

Quality and business value are closely linked. Therefore, it is critical to understand the quality and scope of a project in order to correctly map the outcomes and benefits the project and its product must achieve in order to deliver business value. To determine the business value of a product, it is important to understand the business need that drives the requirements of the product. Thus, business need determines the product required, and the product, in turn provides the expected business value.

Quality is a complex variable. An increase in scope without increasing time or resources tends to reduce quality. Similarly, a reduction in time or resources without decreasing scope also generally results in a decrease in quality. Scrum believes in maintaining a “sustainable pace” of work, which helps improve quality over a period of time.

The Scrum Guidance Body may define minimum quality requirements and standards required for all projects in the organization. The standards must be adhered to by all Scrum Teams in the company.

The Prioritized Product Backlog is a single requirements document that defines the project scope by providing a prioritized list of features of the product or service to be delivered by the project. The required features are described in the form of User Stories. User Stories are specific requirements outlined by various business stakeholders as they pertain to the proposed product or service. Each User Story will have associated User Story Acceptance Criteria (also referred to as “Acceptance Criteria”), which are the objective components by which a User Story’s functionality is judged. Acceptance Criteria are developed by the Product Owner according to his or her expert understanding of the customer’s requirements. The Product Owner then communicates the User Stories in the Prioritized Product Backlog to the Scrum Team members and their agreement is sought. Acceptance Criteria should explicitly outline the conditions that User Stories must satisfy. Clearly defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project.

At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject individual deliverables and their associated User Stories. If deliverables are accepted by the Product Owner, then the User Story is considered Done. A clear definition of Done is critical because it helps clarify requirements and allows the team to adhere to quality norms. It also helps the team think from the user’s perspective when working with User Stories.

User Stories corresponding to rejected deliverables are added back to the Prioritized Product Backlog to be completed in future Sprints. The rejection of a few individual deliverables and their corresponding User Stories is not a rejection of the final product or product increment. The product or product increment could be potentially shippable even if a few User Stories are rejected.

Acceptance Criteria are the product characteristics, specified by the Product Owner, that need to be satisfied before they are accepted by the user, customer, or other authorized entity. These are used as standards to measure and compare the characteristics of the final product with specified characteristics.

Acceptance Criteria are unique to each User Story and are not a substitute for a requirements list.

It is important for a Product Owner to note that User Stories that fulfill most, but not all, Acceptance Criteria cannot be accepted as Done. Scrum projects operate in Time-boxed Sprints, with a dedicated Sprint Backlog for each Sprint. Often, the last bit of work might be the most complicated part of a User Story and might take longer than expected. If incomplete User Stories were given partial credit for being Done and carried over to the next Sprint, then the progress of the subsequent Sprint could be disrupted. Therefore, the Done status is black and white. A User Story can only be either Done or not Done.

Definition of Ready is a set of rules applicable to the product backlog items (User Stories). Definition of Ready defines the criteria that a User Story will have to satisfy before being considered for estimation or inclusion into a Sprint. Definition of Ready puts the onus on the Product Owner to define requirements properly in the User Story - because without properly defined requirements, it will be impossible to get reliable estimates and the Scrum Team will not be able to work on the requirements of a User Story.

The Definition of Ready should preferably be defined by the Scrum Guidance Body. However, there can be project or organizational specific Definition of Ready Criteria that may need to be added or updated by the Product Owner. There may also be additions or updates to the Definition of Ready from the Scrum team.

Scrum Team will commit to take up those User Stories which satisfy the Definition of Ready criteria. Review of product backlog items against the Definition of Ready criteria is a continuous activity as part of the Refine Prioritized Product Backlog process.

Some of the Definition of Ready criteria could be

• User Stories are written in enough detail so that they can be understood by the Scrum Teams and can be used for estimates
• All User Stories have well defined Acceptance Criteria
• Include any related documentation that could provide more clarity about the User Story
• User Stories should not be a large and each User Story should have been broken down in such a way that it can be taken up and completed in a sprint.

There is one key difference between “Done Criteria” and “Acceptance Criteria.” While Acceptance Criteria are unique for individual User Stories, Done Criteria are a set of rules that are applicable to all User Stories in a given Sprint. General Done Criteria could include any of the following:

• Reviewed by other team members
• Completed unit testing of the User Story
• Completion of quality assurance tests
• Completion of all documentation related to the User Story
• All issues are fixed
• Successful demonstration to business stakeholders and/or business representatives

As with the Acceptance Criteria, all conditions of the Done Criteria must be satisfied for the User Story to be considered Done.

The Scrum Team should use a checklist of the general Done Criteria to ensure a task is finished and the result meets the Definition of Done (DoD). A clear Definition of Done is critical because it helps remove ambiguity and allows the team to adhere to required quality norms.

The Definition of Done is typically determined and documented by the Scrum Guidance Body. However, there can be project or organizational specific Done Criteria that may need to be added or updated. There may also be additions or updates to the Done Criteria from the Scrum team.

The required records and data to comply with the project’s documentation requirements can be generated as the team proceeds through Sprints and Releases.

The inclusion of activities such as holding review meetings and writing design documents can help ensure compliance with internal and external quality standards. The basic principles of Scrum such as short iterations, incremental building, customer involvement, adaptation to changing requirements, and constantly adjusting scope, time, and cost within the project will still apply.

Toward the end of any iteration, the respective business unit and business stakeholders participate in a Sprint Review Meeting in which the product increment is demonstrated to the Product Owner, sponsor, customer, and users. While feedback from all the business stakeholders is gathered, only the Product Owner has the power to accept or reject a particular User Story as Done, according to the agreed upon Acceptance Criteria. Thus, the role of Acceptance Criteria in maintaining quality is critical and needs to be clearly understood by the team. It is the responsibility of the Scrum Master to ensure that the Acceptance Criteria for a User Story are not changed by the Product Owner in the middle of a Sprint. Partially completed User Stories are rejected as not Done and moved back into the Prioritized Product Backlog.

The customer is the most important business stakeholder for any project. Therefore, it is important to understand the customer’s needs and requirements. The Voice of the Customer (VOC) can be referred to as the explicit and implicit requirements of the customer, which must be understood prior to the designing of a product or service. Generally, in a Scrum environment, the Product Owner’s focus is on business requirements and objectives, which together represent the Voice of the Customer. The Product Owner can benefit greatly from the guidance available from the Scrum Guidance Body (either through quality documents or standards, or from quality experts). These specialists should work with the Product Owner and the customer to ensure the appropriate level of detail and information in the User Stories, since User Stories are the basis for the success of any Scrum project.

 It should be noted that external business stakeholders are not directly involved at the Scrum Team level and, instead, interact primarily with the Product Owner. For any Scrum project, the customer may be either of the following:

• Internal (that is, within the same organization)
• External (that is, outside the organization)

Quality management in Scrum enables customers to become aware of any problems in the project early and helps them recognize if a project is going to work for them or not. In Scrum, quality is about customer satisfaction and a working product, not necessarily meeting arbitrary metrics. This distinction becomes very important from the customer’s point of view because they are the ones investing time and money in the project.

Quality management in Scrum is facilitated through three interrelated activities:

• Quality planning
• Quality control
• Quality assurance

The Plan-Do-Check-Act Cycle—also known as the Deming or Shewhart Cycle—was developed by Dr. W. Edwards Deming, considered the father of modern quality control and Dr. Walter A. Shewhart. The following are some important points of Deming’s philosophy:

Management guidelines define quality. When management is able to provide a conducive environment and is able to motivate its employees to improve quality on a continuous basis, each employee will be able to make a contribution toward a superior quality product. Deming’s “Theory of Profound Knowledge” advocates what management should do in order to create an environment in which each employee can make significant contributions to quality improvement.

Deming modified Plan-Do-Check-Act to Plan-Do-Study-Act (PDSA) because he felt the term ‘Study’ emphasized analysis rather than simply inspection, as implied by the term ‘Check.’

Both Scrum and the Deming/Shewhart/PDCA Cycle are iterative methods that focus on continuous improvement. The below figure illustrates the stages of the PDCA Cycle and their correlation with various Scrum processes.

Change is inevitable in all projects. In today’s hypercompetitive world where technology, market conditions, and business patterns are continuously shifting, change is the only constant.

A primary principle of Scrum is its acknowledgement that a) business stakeholders (e.g., customers, users, and sponsors) do change their minds about what they want and need throughout a project (sometimes referred to as ‘requirements churn’) and b) that it is very difficult, if not impossible, for business stakeholders to define all requirements during project initiation.

Scrum development projects welcome change by using small development cycles that incorporate customer feedback on the project’s deliverables after each Sprint. This enables the customer to regularly interact with the Scrum Team members, view product increments as they are ready, and change requirements earlier on in the development cycle. Also, the portfolio or program management teams can respond to Change Requests pertaining to Scrum projects applicable at their level.

Scrum embodies a key principle from the Agile Manifesto (Fowler and Highsmith, 2001): “Responding to change over following a plan.” Scrum is practiced on the basis of embracing change and turning it into a competitive advantage. Therefore, it is more important to be flexible than to follow a strict, predefined plan. This means it is essential to approach project management in an adaptive manner that enables change throughout rapid product development or service development cycles.

Being adaptive to change is a key advantage of the Scrum framework. Although Scrum works well for all projects in all industries, it can be very effective when the product or other project requirements are not fully understood or cannot be well defined up front, when the product’s market is volatile, and/or when the focus is on making the team flexible enough to incorporate changing requirements. Scrum is especially useful for complex projects with a lot of uncertainty. Long-term planning and forecasting is typically ineffective for such projects and they involve high quantities of risk. Scrum guides the team through transparency, inspection, and adaptation to the most valuable business outcomes.

Request for changes are usually submitted as Change Requests. Change Requests remain unapproved until they get formally approved. The Scrum Guidance Body usually defines a process for approving and managing changes throughout the organization. In the absence of a formal process, it is recommended that small changes that do not have significant impact on the project be directly approved by the Product Owner. The tolerance for such small changes could be defined at an organizational level or by the sponsor for a particular project. In most projects, 90% of Change Requests could be classified as small changes that should be approved by the Product Owner. So, the Product Owner plays a very important role in managing changes in a Scrum Project.

Changes that are beyond the approval level of the Product Owner may need approval from relevant business stakeholders working with the Product Owner.

At times, if a requested change could have a substantial impact on the project or organization, approval from senior management (e.g., Executive Sponsor, Portfolio Product Owner, Program Product Owner, or Chief Product Owner) may be required.

Change Requests for the project are discussed and approved during the Develop Epic(s), Create Prioritized Product Backlog, and Refine Prioritized Product Backlog processes. Approved Change Requests are then prioritized along with other product requirements and their respective User Stories and then incorporated into the Prioritized Product Backlog.

The below figure summarizes the change approval process.

                                                      Sample Change Approval Process

The below figure summarizes how Prioritized Product Backlog is updated with approved changes.

Updating Prioritized Product Backlog with Approved Changes

If there is a Change Request that may have significant impact on a Sprint in progress, the Product Owner, after consultation with relevant business business stakeholders, decides whether the change can wait until the next Sprint or represents an urgent situation which may require ending the current Sprint and starting a new one.

Scrum framework clearly specifies that the scope of a Sprint cannot be changed once the Sprint begins. If the required change is so important that the results of the Sprint would be worthless without it, then the Sprint should be terminated. If not, then the change is incorporated into a later Sprint (as shown in figure below).

There is only one exception to this rule about not changing the scope of a Sprint once a Sprint begins. If the Scrum Team determines it has heavily overestimated the effort during the Sprint and has spare capacity to implement additional User Stories, the team can ask the Product Owner which additional User Stories should be included in the current Sprint.

By locking down the scope of every Sprint, the team is able to efficiently optimize and manage their work and effort. An additional benefit is that the team does not have to worry about managing changes once they start working on a Sprint. This is a big advantage of the Scrum framework as compared with traditional project management.

In traditional project management, changes can be requested and approved anytime during the project’s lifecycle. This often creates confusion for project team members, decreases team motivation due to discontinuity, and results in a lack of focus and the team feeling that “nothing ever gets done.” On the other hand, in Scrum projects, changes are not allowed once a Sprint starts. This ensures that in every Sprint, the team completes deliverables and tasks are Done. Furthermore, the business recognizes tangible benefits from potentially shippable Deliverables at the end of each Sprint.

Moreover, since the Product Owner and Business stakeholders are aware that changes are not allowed once a Sprint begins and a Sprint lasts between 1 and 6 weeks, they define and prioritize requirements during the appropriate processes of Create Epic(s), Create Prioritized Product Backlog, and Refine Prioritized Product Backlog.

Because changes are not allowed during a Sprint, the impact and frequency of expected changes may have an impact on the decision related to the length of the Sprint when it is determined during the Conduct Release Planning process.

If project requirements are generally stable and major changes are not expected in the near future, the Length of a Sprint may be set to be longer, 4 to 6 weeks. This provides stability to the Scrum Team members to work on the Prioritized Product Backlog requirements for lengthy periods of time without having to go through the Create User Stories, Estimate User Stories, Commit User Stories, Identify Tasks, Estimate Task, and other related processes that are conducted for every Sprint.

However, if project requirements are not very well defined or if significant changes are expected in the immediate future, the Length of Sprint may be relatively shorter, 1 to 3 weeks. This provides stability to the Scrum Team members to work on shorter Sprints and deliver results, which can be evaluated by the Product Owner and Business stakeholders at the end of the Sprint. This also provides enough flexibility for them to clarify requirements and make changes to the Prioritized Product Backlog at the end of each Sprint.

A Sprint could be Time-boxed from 1 to 6 weeks. Most Scrum projects typically use Sprints which are Time-boxed to 2-4 weeks, or less. However, if there are projects with very stable requirements, Sprints can extend up to 6 weeks.

                                      Impact of expected change on the Length of Sprint.

It is important to note that expected change is not the only factor used to determine the Length of Sprint. Other factors that also need to be considered include:

• Actual time to get work done (if the project or corporate environment needs a specific time to get tasks done, that could determine the Length of Sprint)
• Planned date for a release (the Length of Sprint should take into consideration the release dates for the overall product or service)
• Any other factor as determined by the Product Owner or Scrum Master, that need to be considered while determining the Length of Sprint

It is important to note that changing the Length of Sprint should not be decided lightly or periodically (e.g. it is not advisable to have the sprint length as 3 weeks this sprint, 2 weeks the next, 4 weeks for the third sprint etc.) Length of Sprint should preferably be consistent.  One of the greatest impacts of changing the Length of Sprint is that it causes a reset on all tracking at the project level.  Previous velocities may become useless for forecasting and planning of future Sprints.  Without an accurate velocity (which is a primary metric in any scrum project), the Scrum Team cannot be measured for effectiveness or adequately choose the number of User Stories to take on when planning for the sprint. So, once the Length of Sprint is decided, it should preferably be kept constant over the duration of the project or through multiple Sprint cycles.

Risk is defined as an uncertain event that can affect the objectives of a project and may contribute to its success or failure. Risks with a potential for positive impact on the project are called opportunities, whereas threats are risks that could negatively impact a project. Managing risk must be done proactively, and it is an iterative process that should begin at project inception and continue throughout the life of the project. The process of managing risk should follow some standardized steps to ensure that risks are identified, evaluated, and a proper course of action is determined and acted upon accordingly.

Risks should be identified, assessed, and responded to based primarily on two factors: the probability of an occurrence and the probable impact in the event of the occurrence. Risks with high probability and high impact rating should be addressed before those with a lower rating. In general, once a risk is identified, it is important to understand the basic aspects of the risk with regard to the possible causes, the area of uncertainty, and the potential effects if the risk occurs.

Difference between Risks and Issues.

Risks are the uncertainties related to a project that could significantly alter the outcome of the project in a positive or negative way. Since risks are future uncertainties, they have no current impact on the project, but could have a potential impact on the future. The following are some examples of risks:

• Even after extensive training, the customer service representatives might not be ready to take orders on the go-live date.
• The painting crew might be delayed due to heavy rain, which could negatively impact the project schedule.

Issues are generally well-defined certainties that are currently happening on the project: so there is no need for conducting a probability assessment as we would for a risk. Issues must be dealt with. Some examples of issues include the following:

• Funding is not approved.
• Requirements are unclear.

Risks, if not addressed in time, may become issues. The goal of risk management is to be prepared, with plans in place to deal with any risks that may occur.

Business stakeholders include all people or organizations impacted by the project as well as those that have the ability to impact the project. It is important to understand the risk attitude of the business stakeholders. Risk attitude is influenced by the following three factors:

• Risk appetite: refers to how much uncertainty the business stakeholder or organization is willing to take on.
• Risk tolerance: indicates the degree, amount, or volume of risk business stakeholders will withstand.
• Risk threshold: refers to the level at which a risk is acceptable to the business stakeholder organization. A risk will fall above or below the risk threshold. If it is below, then the business stakeholder or organization is more likely to accept the risk.

Essentially, the risk attitude of the business stakeholders determines how much risk the business stakeholders consider acceptable and hence when they will decide to take actions to mitigate potential adverse impacts of risks. Therefore, it is important to understand the tolerance levels of the business stakeholders in relation to various factors including cost, quality, scope, and schedule.

Utility Function is a model used for measuring business stakeholder risk preference or attitude toward risk. It defines the business stakeholders’ level or willingness to accept risk. The three categories of Utility Function are the following:

• Risk averse: Business stakeholder is unwilling to accept a risk no matter what the anticipated benefit or opportunity.
• Risk neutral: Business stakeholder is neither risk averse nor risk seeking and any given decision is not affected by the level of uncertainty of the outcomes. When two possible scenarios carry the same level of benefit, the risk neutral business stakeholder will not be concerned if one scenario is riskier than the other.
• Risk seeking: Business stakeholder is willing to accept risk even if it delivers a marginal increase in return or benefit to the project.

Risk Management consists of the following five steps, which should be done iteratively throughout the project:

• Risk identification: Using various techniques to identify all potential risks.
• Risk assessment: Evaluating and estimating the identified risks.
• Risk prioritization: Prioritizing risk to be included in the Prioritized Product Backlog.
• Risk mitigation: Developing an appropriate strategy to deal with the risk.
• Risk communication: Communicating the findings from the first four steps to the appropriate business stakeholders and determining their perception regarding the uncertain events.

Being an Agile, iterative process, the Scrum framework inherently minimizes risk. The following Scrum practices facilitate the effective management of risk:

• Flexibility reduces business-environment-related risk - Risk is largely minimized in Scrum due to the flexibility in adding or modifying requirements at any time in the project lifecycle. This enables the organization to respond to threats or opportunities from the business environment and unforeseen requirements whenever they arise, with usually low cost of managing such risks.
• Regular feedback reduces expectations-related risk - Being iterative, the Scrum framework gives ample opportunities to obtain feedback and set expectations throughout the project lifecycle. This ensures that the project business stakeholders, as well as the team, are not caught off guard by miscommunicated requirements.
• Team ownership reduces estimation risk - The Scrum Team estimates and takes ownership of the Sprint Backlog Items, which leads to more accurate estimation and timely delivery of product increments
• Transparency reduces non-detection risk - The Scrum principle of transparency around which the framework is built ensures that risks are detected and communicated early, leading to better risk handling and mitigation. Moreover, when conducting Scrum of Scrums Meetings, Impediments that one team is currently facing may be deemed a risk for other Scrum Teams in the future. This should be recognized in the Updated Impediments Log.
• Iterative delivery reduces investment risk - Continuous delivery of value throughout the Scrum project lifecycle, as potentially shippable Deliverables are created after every Sprint, reduces investment risk for the customer.