The Scrum Tool

The Scrum tool applies to the following:

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

The term “product” may refer to a product, service, or other deliverable. Scrum can be applied effectively to any project in any industry—from small projects or teams with as few as six team members to large, complex projects with up to several hundred team members.

Overview of the Scrum Tool

A Scrum project involves a collaborative effort to create a new product, service, or other result as defined in the Project Vision Statement. Projects are impacted by constraints of time, cost, scope, quality, resources, organizational capabilities, and other limitations that make them difficult to plan, execute, manage, and ultimately succeed. However, successful implementation of the results of a finished project provides significant business benefits to an organization. Therefore, importantly, organizations must select and practice an appropriate project management methodology.

Scrum is one of the most popular Agile methodologies. It is an adaptive, iterative, fast, flexible, and effective methodology designed to deliver significant value quickly and throughout a project. Scrum ensures transparency in communication and creates an environment of collective accountability and continuous progress. The Scrum tool framework supports product and service development in all types of industries and in any type of project, irrespective of its complexity.

A key strength of the Scrum tool lies in its use of cross-functional, self-organized, and empowered teams who divide their work into short, concentrated work cycles called Sprints. The above figure provides an overview of a Scrum project’s flow.

The Scrum cycle begins with a stakeholder meeting, during which they create the Project Vision. The Product Owner then develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of User Stories.

Each Sprint begins with a Sprint Planning Meeting. The team considers which high priority User Stories are for inclusion in the Sprint. A Sprint generally lasts between one and six weeks and involves the Scrum Team working to create potentially shippable Deliverables or product increments.

During the Sprint, short, you conduct highly focused Daily Standup Meetings where the team members discuss daily progress. Toward the end of the Sprint, you hold a Sprint Review Meeting. Here, the team provides the Product Owner and relevant stakeholders a demonstration of the Deliverables.

The Product Owner accepts the Deliverables only if they meet the predefined Acceptance Criteria. The Sprint cycle ends with a Retrospect Sprint Meeting where the team discusses ways to improve processes and performance as they move forward into the subsequent Sprint.

Brief History of Scrum

In the mid 80’s, Hirotaka Takeuchi and Ikujiro Nonaka defined a flexible and all-inclusive product development strategy where the development team works as a unit to reach a common goal.

They described an innovative approach to product development that they called a holistic or “rugby” approach, “where a team tries to go the distance as a unit, passing the ball back and forth.” They based their approach on manufacturing case studies from various industries.

Takeuchi and Nonaka proposed that product development should not be like a sequential relay race, but rather should be analogous to the game of rugby where the team works together, passing the ball back and forth as they move as a unit down the field. They introduced the rugby concept of a “Scrum” (where a group of players form together to restart the game) to describe product development as moving the Scrum downfield.

Ken Schwaber and Jeff Sutherland elaborated on the Scrum Tool concept and its applicability to software development in a presentation at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) conference held in 1995 in Austin, Texas. Since then, several Scrum practitioners, experts and authors continued to refine the Scrum conceptualization and methodology.

In recent years, Scrum has increased in popularity and is now the preferred project development methodology for many organizations globally.

Why Use Scrum?

Some of the key benefits of using the Scrum Tool in any project include...

1. Adaptability—Empirical process control and iterative delivery make projects adaptable and open to incorporating change.

2. Transparency—The team shares all information radiators like a Scrumboard and Sprint Burndown Charts leading to an open work environment.

3. Continuous Feedback—The team provides continuous feedback through the Conduct Daily Standup, which demonstrates and validates Sprint processes.

4. Continuous Improvement—The Sprint improves the deliverables progressively through the Groomed Prioritized Product Backlog process.

5. Continuous Delivery of Value—Iterative processes enable the continuous delivery of value through the Ship Deliverables process as frequently as the customer requires.

6. Sustainable Pace—People involved work at a sustainable pace that they can, in theory, continue indefinitely.

7. Early Delivery of High Value—The Create Prioritized Product Backlog process ensures that the highest value requirements of the customer are satisfied first.

8. Efficient Development Process—Time-boxing and minimizing non-essential work leads to higher efficiency levels.

9. Motivation—The Conduct Daily Standup and Retrospect Sprint processes lead to greater levels of motivation among employees.

10. Faster Problem Resolution—Collaboration and collocation of cross-functional teams lead to faster problem solving.

11. Effective Deliverables—The Create Prioritized Product Backlog process and regular reviews after creating deliverables ensures effective deliverables to the customer.

12. Customer Centric—Emphasis on business value and a collaborative approach to stakeholders ensures a customer-oriented framework.

13. High Trust Environment—Conduct Daily Standup and Retrospect Sprint processes promote transparency and collaboration, leading to a high trust work environment ensuring low friction among employees.

14. Collective Ownership—The Approve, Estimate, and Commit User Stories process allows team members to take ownership of the project and their work leading to better quality.

15. High Velocity—A collaborative framework enables highly skilled cross-functional teams to achieve their full potential and high velocity.

16. Innovative Environment—The Retrospect Sprint and Retrospect Project processes create an environment of introspection, learning, and adaptability leading to an innovative and creative work environment.

Scalability of Scrum

To be effective, Scrum Teams should ideally have six to ten members. This practice may be the reason for the misconception that the Scrum framework can only be used for small projects.

However, it can easily be scaled for effective use in large projects. In situations where the Scrum Team size exceeds ten people, you form multiple Scrum Teams to work on the project. The Convene Scrum of Scrums process facilitates coordination among the Scrum Teams, enabling effective implementation in larger projects.

You implement large or complex projects as part of a program or portfolio. You can apply The Scrum tool to manage even programs and portfolios. The logical approach of the guidelines and principles in this framework can be used to manage projects of any size, spanning geographies and organizations.

Large projects may have multiple Scrum Teams working in parallel making it necessary to synchronize and facilitate the flow of information and enhance communication. The Convene Scrum of Scrums ensures this synchronization. Here, the various Scrum tool teams represent in this meeting and provide the objectives and updates about progress. They discuss challenges faced during the project, and coordinate activities.

There are no set rules regarding the frequency of these meetings. The factors that determine the frequency include

• the amount of inter-team dependency
• size of the project
• level of complexity
• recommendations from the Scrum Guidance Body