Implementing Scrum in Organizations

Scrum is not your regular waterfall technique but an agile framework which changes and, at times, challenges traditional roles. The Organizational Resource Matrix is a hierarchical depiction of a combination of a functional organizational structure and a projectized organizational structure. Matrix organizations bring together team members for a project from different functional departments such as information technology, finance, marketing, sales, manufacturing, and other departments – and create cross-functional teams. Managers, developers, and testers will be assigned the roles of the Product Owner, the Scrum Master, and the Development Team (Scrum Team).

The Skills Requirement Matrix, also known as a competency framework, is used to assess skill gaps and training requirements for team members. A skills matrix maps the skills, capabilities, and interest level of team members in using those skills and capabilities on a project. Using this matrix, the organization can assess any skill gaps in team members and identify the employees who will need further training in a particular area or competency. Team members may not always possess the required knowledge or skills to work in the Scrum environment. The Product Owner should evaluate the training needs of potential team members and facilitate training to bridge any knowledge gaps in the team.

The Product Owner is normally responsible for evaluating and selecting team members, but often does this in consultation with the Scrum Master who may have additional knowledge of the resources from working with them on other projects. Appropriate training should be provided to the Scrum Team members both prior to the commencement of work, and also when they are working on their projects. Scrum Team members should also be ready to learn from each other and from more experienced persons in the team. The awareness level of Scrum in an organization needs to be assessed which will help probe into the readiness of an organization and its people for Scrum.

There are different aspects of an organization that needs to be gauged: organizational, infrastructural, business, team, technological, and procedural. The results of the assessment will allow for a more specific awareness generation or training in the area concerned.  Product Managers, Project Managers, Functional / Departmental Managers, Scrum Team Members (including Architects, Designers, Coders, Testers, and others), and Executives in organizations doing Scrum must be provided with the right level of insight into Scrum for its successful implementation. Insight should not just be provided to the core roles (Product Owner, Scrum Master, and Scrum Team) but should also extend to the non-core roles (Users, Stakeholders, Consulting Experts, and Management).

Creating a good cooperation and continuous exchange of information between these two roles is crucial to the success of a project. The non-core roles have to be actively involved in envisioning the product and providing feedback as to “what” should constitute the desired product. The Scrum Team and the Product Owner should be left to figure out the “how” of achieving the desired results.  Changed to Scrum team. Therefore, the Scrum Team must be trained to actively seek feedback from the Product Owner who funnels the feedback from the other non-core roles, and those stakeholders must be sensitized well in the practices of Scrum so that they do not interfere with the workings of the Scrum Team.

For a well-developed Scrum implementation in an organization, the level of awareness about Agile principles and values must be extensive. The Scrum Team has to be sensitized and trained in the ways of Scrum and the Scrum Master should act like a coach. The Scrum Master needs to bring out the best from the Scrum team by motivating them and facilitating the development process. Apart from the Scrum Team, the Product Owner also needs to be trained well.  The Product Owner is the bridge between requirements and development. The more he/she is able to understand the requirements the better product development will be.

Implementation of Scrum changes not just the development team or a few management executives associated with a team or a project but at every level of the organization. Change at an organizational level is complex and is influenced by various factors: the culture of an organization, insecurity of managers, employee resistance, failure to see the need for change, fear of the unknown. These hurdles need to be addressed professionally by the Scrum Master. Clear objectives need to be communicated to all personnel about the implementation of Scrum.

For interesting articles about Scrum and Agile, visit


6 Main Principles of Scrum Methodology

Scrum principles are the foundation on which the Scrum framework is based. The principles of Scrum can be applied to any type of project or organization, and they must be adhered to in order to ensure appropriate application of Scrum.

The aspects and processes of Scrum can be modified to meet the requirements of the project, or the organization using it, but Scrum principles are non-negotiable and must be applied as described in the framework presented in A Guide to the Scrum Body of Knowledge the SBOK™ Guide. Keeping the principles intact and using them appropriately instills confidence in the Scrum framework with regard to attaining the objectives of the project.

  • Empirical Process Control—This principle emphasizes the core philosophy of Scrum based on the three main ideas of transparency, inspection, and adaptation.
  • Self-organization—This principle focuses on today’s workers, who deliver significantly greater value when self-organized and this results in better team buy-in and shared ownership; and an innovative and creative environment which is more conducive for growth.
  • Collaboration—This principle focuses on the three core dimensions related to collaborative work: awareness, articulation, and appropriation. It also advocates project management as a shared value-creation process with teams working and interacting together to deliver the greatest value.
  • Value-based Prioritization—This principle highlights the focus of Scrum to deliver maximum business value, from early in the project and continuing throughout.
  • Time-boxing—This principle describes how time is considered a limiting constraint in Scrum, and used to help effectively manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint Planning Meetings, and Sprint Review Meetings.
  • Iterative Development—This principle defines iterative development and emphasizes how to better manage changes and build products that satisfy customer needs. It also delineates the Product Owner’s and organization’s responsibilities related to iterative development.

Scrum principles are the core guidelines for applying the Scrum framework and should mandatorily be used in all Scrum projects. The Scrum aspects and processes, however, can be modified to meet the requirements of the project or the organization.


For interesting articles about Scrum and Agile, visit

Scalability of Scrum

Scalability of a process, network, or unit is its ability to adjust or adapt to any expansion. For example a central server is said to be scalable if it performs similarly when attending on either five clients or fifty clients. In Scrum, it means that the scaling mechanisms applicable for a single Scrum Team can also be used for larger projects with multiple teams.

Is Scrum scalable? Initially, Agile authors believed that Agile methodologies including Scrum was predominantly for small scale projects. This opinion was based on the fact that Scrum had not yet been applied on large scale projects. The Guide to the Scrum Body of Knowledge (SBOK™ Guide) gives comprehensive directions through which Agile methodologies including Scrum, can be scaled and applied on larger projects

When to scale? In small Scrum projects there is adequate scope for the self-organizing Scrum Team members to collaborate among themselves. The problem starts when team size expands and when there is coordination required between multiple teams. Scalability in Scrum can occur at three levels – Projects, Programs and Portfolios

How to scale? Scalability in Scrum is achieved primarily through the Scrum of Scrum (SoS) Meetings. Scrum recommends small teams; however if teams are larger it is recommended that they are divided into smaller teams who can meet occasionally to discuss their status.

What makes Scrum scalable? It is recommended that Scrum Teams should ideally have six to ten members. This does not mean that Scrum can be used only in small projects – it can be scaled to be used effectively in larger projects. If the size of the Scrum Team exceeds ten members, then multiple teams can be formed to work on the project simultaneously.

Scrum of Scrums facilitates synchronization between multiple Scrum Teams in larger projects. Team representatives update each other about team’s progress, challenges faced and coordination activities. Frequency of Scrum of Scrums (SoS) Meetings is determined by inter-team dependency, size of the project, recommendations by Scrum Guidance Body (SGB) and complexity level.
Scaling in Distributed Teams:

Scrum recommends collocated teams and face-to-face communication between team members. This is often not possible, as companies have distributed teams working in parallel across geographies and time zones. For the purpose of scaling, in larger projects employing distributed teams, the Scrum of Scrum Meeting can be held using video conferencing, chats, social media etc.

The ‘Convene Scrum of Scrums’ Process is facilitated by the Chief Scrum Master (or another Scrum Master). Representatives of various teams, usually the Scrum Master of individual teams or any other designated team member. For larger projects, involving a significant number of teams, multiple levels of these meetings may be convened. In larger projects, as it is difficult to have all participants together at one time, all important matters should be discussed

The Scrum of Scrums meeting is usually held at predetermined intervals or when required, to collaborate and track progress, address impediments and dependencies across projects. An agenda for the meeting can be announced in advance by the Chief Scrum Master, allowing individual teams to consider the items for discussion. Impediments faced by individual teams, likely to affect other teams should also be indicated. Issues, risks and changes likely to affect multiple teams should also be communicated during this meeting.

Achieving Scalability:

Each team representative is expected to update other teams, usually in the form of four questions. (i) What has my team been working on since the last meeting?, (ii) What will my team do until the next meeting?, (iii) What were other teams counting on our team to finish that remains undone?, (iv) What is our team planning on doing that might affect other teams?

Result of Scrum of Scrums Meetings include Better Team Coordination facilitated coordination of work across multiple Scrum Teams, especially when there are tasks involving inter-team dependencies (as future tasks of one team may depend on the timely delivery of a task by another team). Discrepancies between work and deliverables are quickly exposed. The Scrum of Scrums is a forum where team members can transparently discuss issues and resolve them.

Scrum of Scrum of Scrums: In organizations that have several Scrum projects happening simultaneously, the Scrum of Scrums Meeting can be scaled up another level to a Scrum of Scrum of Scrums meeting. In this situation, a separate Scrum of Scrums Meeting is held to coordinate each group of projects that are directly related to each other.

For interesting articles about Scrum and Agile, visit

How do Scrum Teams Estimate Tasks in a Project?

Task planning and estimation is vital to develop products iteratively in accordance with the requirements specified in the Prioritized Product Backlog. The Scrum Team, in Task Estimation Meetings, estimates the effort required to accomplish each task in the Task List. The result of this process is an Effort Estimated Task List. The Scrum Team uses the Task list, a comprehensive list containing all the tasks to which the team has committed for the current Sprint, to develop an Effort Estimated Task List. The Task List must include any testing and integration efforts so the product increment from the Sprint can be successfully integrated into the deliverables from previous Sprints. Even though tasks are often activity based, the level of granularity to which the tasks are decomposed is decided by the Scrum Team.

During Task Estimation Meetings, the Scrum Team uses the Task List to estimate the effort required to complete a task or set of tasks and to estimate the people effort and other resources required to carry out the tasks within a given Sprint. One of the key benefits of this technique is that it enables the team to have a shared perspective of the User Stories and requirements so that they can reliably estimate the effort required. The information developed in the Task Estimation Meetings is included in the Effort Estimated Task List, and it is used to determine the velocity for the Sprint. In this workshop, the Scrum Team may use various techniques such as decomposition, expert judgment, analogous estimation, and parametric estimation. Task Estimation Meetings may also be combined with Task Planning Meetings.

To maintain relative estimation sizes and minimize the need for re-estimation the team uses estimation criteria. Estimation criteria can be expressed in numerous ways, with two common examples being story points and ideal time. For example, an ideal time normally describes the number of hours a Scrum Team member works exclusively on developing the project’s deliverables, without including any time spent on other activities or work that is outside the project. Estimation criteria make it easier for the Scrum Team to estimate effort and enable them to evaluate and address inefficiencies when necessary.

The output of task estimation is the Effort Estimated Task List. It is a list of tasks associated with the User Stories committed to in a Sprint. Typically, the accuracy of estimates varies with team skills. Estimated effort is expressed in terms of the estimation criteria agreed on by the team. This Effort Estimated Task List is used by the Scrum Team during Sprint Planning Meetings to create the Sprint Backlog and Sprint Burndown Chart.

For interesting articles about Scrum and Agile, visit

Selecting appropriate Scrum Master(s) and identifying relevant Stakeholder(s)

Selecting appropriate Scrum Master(s) and identifying relevant Stakeholder(s) is crucial to the success of any project. In some projects, there may have been pre-conditions stipulating certain team members and their roles.

When there is flexibility in choosing the Scrum Master(s), the following are important Selection Criteria:

  • Problem-solving skills—This is one of the primary criteria to be considered while selecting Scrum Master(s). The Scrum Master(s) should have the necessary skills and experience to help remove any impediments for the Scrum Team.
  • Availability—The Scrum Master should be available to schedule, oversee, and facilitate various meetings, including the Release Planning Meeting, Daily Standup Meeting, and other Sprint-related meetings.
  • Commitment—The Scrum Master should be highly committed to ensure that the Scrum Team is provided with a conducive work environment to ensure successful delivery of Scrum projects.
  • Servant Leadership Style—Servant leaders employ listening, empathy, commitment, and insight while sharing power and authority with team members. Servant leaders are stewards who achieve results by focusing on the needs of the team. This style is the embodiment of the Scrum Master role

When identifying the Stakeholder(s), it is important to remember that stakeholders are all the customers, users, and sponsors, who frequently interface with the Product Owner, Scrum Master, and Scrum Team to provide inputs and facilitate creation of the project’s products. The stakeholders influence the project throughout its lifecycle.

For interesting articles about Scrum and Agile, visit

Risk Burndown Chart

In Scrum, the risk management activities are divided among various roles with some responsibility resting with everyone in the Scrum Team and the Scrum Master facilitating the process. Risk management is integral to ensuring value creation; therefore, risk management activities are performed throughout the project lifecycle and not just during project initiation.

Each risk could be assessed using different Risk Assessment tools. However, the preferred tool for assessing risks to create a Risk Burndown Chart is Expected Monetary Value (EMV).

The information gathered during risk assessment may be used to create a Risk Burndown Chart. This depicts cumulative project risk severity over time. The likelihoods of the various Risks are plotted on top of each other to show cumulative risk on the y-axis. The initial identification and evaluation of risks on the project and the creation of the Risk Burndown Chart are done initially. Then, at predetermined time intervals, new risks may be identified and assessed and remaining risks should be re-evaluated and updated accordingly on the chart. An appropriate time to do this is during the Sprint Planning Meeting. Tracking risks in this manner allows the team to recognize trends in risk exposure and take appropriate action, as necessary.


For interesting articles about Scrum and Agile, visit

Value-based Prioritization in SCRUM

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.

Prioritizing can be defined as determining the order and separating 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 drives 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 has received the business requirements from the customer and written these down in the form of workable User Stories, he or she works with the customer and sponsor to understand which business requirements provide maximum business value. The Product Owner must understand what the customer wants and values in order to arrange the Prioritized Product Backlog Items (User Stories) by relative importance. 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. 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 Groom 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, and financial models and analytical techniques.

The Product Owner has to translate the inputs and needs of the project stakeholders to create the Prioritized Product Backlog. Hence, Value, Risk or uncertainty and Dependencies are the three factors considered while prioritizing the User Stories in the Prioritized Product Backlog.

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


For interesting articles about Scrum and Agile, visit