In order to successfully run a Scrum Project there are five Scrum aspects that must be addressed and managed throughout the project life cycle.
We will see what those aspects are in detail.
Organization
Understanding defined roles and responsibilities in a Scrum project is very important for ensuring the successful implementation of Scrum.
Scrum roles falls into two broad categories:
1. Core Roles—Core roles are those roles which are mandatorily required for producing the project’s product or service. Individuals who are assigned core roles are fully committed to the project and are ultimately responsible for the success of each project iteration and of the project as a whole.
These roles include:
The Product Owner is the person responsible for achieving maximum business value for the project. He/she is also responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer.
The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the project 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.
The Scrum Team is the group or team of people who are responsible for understanding the requirements specified by the Product Owner and creating the Deliverables of the project.
2. 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. They have no formal role in the project team and may interface with the team, but may not be responsible for the success of the project. The non-core roles should be taken into account in any Scrum project.
Non-core roles include the following:
Stakeholder(s), which is a collective term that includes customers, users, and sponsors, frequently interface with the Scrum Core Team, and influence the project throughout the project’s development. Most importantly, it is for the stakeholders that the project produces the collaborative benefits.
Scrum Guidance Body (SGB) is an optional role, which generally consists of a set 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. This SGB guides the work carried out by the Product Owner, Scrum Master, and Scrum Team.
Vendors, including external individuals or organizations provide products and/or services that are not within the core competencies of the project organization.
Chief Product Owner is a role in bigger projects with multiple Scrum Teams. This role is responsible for facilitating the work of multiple Product Owners, and maintaining business justification for the larger project.
Chief Scrum Master is responsible to coordinate Scrum-related activities in large projects which may require multiple Scrum Teams to work in parallel.
The organization aspect of Scrum also addresses the team structure requirements to implement Scrum in programs and portfolios.
Business Justification
It is important for an organization to perform a proper business assessment prior to starting any project. This helps key decision makers understand the business need for a change or for a new product or service, the justification for moving forward with a project, and its viability.
Business justification in Scrum is based on the concept of Value-driven Delivery. 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, Scrum attempts 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 stakeholders.
Scrum’s adaptability allows the project’s objectives and processes to change if its business justification changes. It is important to note that although the Product Owner is primarily responsible for business justification, other team members contribute significantly.
Quality
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 a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and 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.
The fact that Scrum, through repetitive testing, requires work to be completed in an incremental fashion through Sprints rather than waiting until the end to produce deliverables results in errors being fixed right away, rather than postponed. 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 deliverable created as part of a Sprint. Such deliverables from Scrum projects, which are potentially shippable, are also referred to as ‘Done.’
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 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.
The Scrum Guidance Body may also provide guidelines about quality which may be relevant to all Scrum projects in the organization.
Change
Every project, regardless of its method or framework used, is exposed to change. It is imperative that project team members understand that the Scrum development processes are designed to embrace change. Organizations should try to maximize the benefits that arise from change and minimize any negative impacts through diligent change management processes in accordance with the principles of Scrum.
A primary principle of Scrum is its acknowledgement that a) stakeholders (e.g., customers, users, and sponsors) 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 stakeholders to define all requirements during project initiation.
Scrum projects welcome change by using short, iterative Sprints that incorporate customer feedback on each Sprint’s deliverables. This enables the customer to regularly interact with the Scrum Team members, view deliverables as they are ready, and change requirements if needed earlier in the Sprint.
Also, the portfolio or program management teams can respond to Change Requests pertaining to Scrum projects applicable at their level.
Risk
Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. Risks that are likely to have a positive impact on the project are referred to as opportunities, whereas threats are risks that could affect the project in a negative manner. Managing risk must be done proactively, and it is an iterative process that should begin at project initiation and continue throughout the project’s lifecycle. The process of managing risks 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 be based on two factors: the probability of each risk’s occurrence and the possible impact in the event of such occurrence. Risks with a high probability and impact value (determined by multiplying both factors), should be addressed before those with a relatively lower value. In general, once a risk is identified, it is important to understand the risk with regard to the probable causes and the potential effects if the risk occurs.
Other Must Read Posts
