What Makes Scrum the Superior Project Management Platform?
The process of developing modern software applications has become nearly as complex as the programs themselves. Project managers increasingly find themselves challenged to balance changing customer demands, vagueness in the design process, and deadlines that are seldom based on accurate assessments of what’s required to complete the project. Various project management and estimation tools have been developed, with varying degrees of success, but most focus on tweaking the standard sequential process of software development known as the waterfall method. In this article, we will examine the advantages of Scrum, and we will see why it provides a win-win situation for both client and developer.
The term Scrum derives from a strategy in the game of rugby in which a team attempts to gain or keep possession of the ball by team members locking arms with their heads down. The implication for Software development is the unifying of the team in order to achieve a common goal. Yes, development teams have always worked together in that sense, but the goal has traditionally been completion of the final version of a software product. Scrum, by comparison, breaks the larger project down into small, manageable tasks, and the project progresses through numerous iterations, or revisions, of these tasks until the project meets the expectations of the client.
Scrum vs Agile
You may see the terms Scrum and Agile used interchangeably on certain websites. It is important to note that, while related, Scrum and Agile are not the same thing.
Agile is a project management methodology based on iterative and incremental methods of managing product design. Although there are several subsets of Agile, each representing a slightly different approach to project management, all Agile methodologies have these key elements: communication, collaboration, the importance of software, and flexibility.
Scrum is the most popular of Agile project management techniques for software development. What separates Scum from other methods is, as we shall discuss shortly, the use of three roles for managing projects.
The Scrum Methodology
As we mentioned, the traditional method of software development follows a sequence: plan, build, test, review, deploy. This system has some significant disadvantages.
First, the process fails to involve the customer except during the planning and review/deployment stages. The result is often a finished product that fails to reflect changing customer needs that materialize during the development stage. If the customer decides they want changes after the planning stage has been completed, those changes can require significant time and cost to implement.
Second, the inherent inflexibility of the process means that mistakes or change requests can delay getting the product to market.
What makes the Scrum methodology a superior project management methodology is that it is not so much a methodology as a framework. Rather than following a rigid process, Scrum uses a simple, lightweight structure that allows flexibility and changes from project initiation through the final release of the product. Whereas the waterfall method aims to build one product that meets the initial design requirements of the customer, Scrum results in several revisions of a completed product being built. Each revision produces a potentially shippable product. Each iteration adds progressively more functionality to the product than the previous one. However, even the first version produces a functioning and tested product — albeit with a minimal feature set — that the customer could market if they so choose.
To accomplish this, Scrum relies on a system of artifacts, roles, and ceremonies to ensure that projects stay on track.
Artifacts represent information about the product and about the project’s progress. The official Scrum Process Framework defines the following minimum artifacts for a Scrum project.
Each feature that the customer wants to see in the final product is described in simple terms from the perspective of the end user, and is called a User Story. The Product Backlog is the collection of all User Stories and is, essentially, a prioritized wish list of what the features the customer wants.
The Sprint Backlog contains tasks, or User Stories, that the Scrum team has decided to develop during the first revision of the product. The process of developing each version is known as a Sprint. Sprints break the larger project into short-duration milestones, and are generally completed in less than a week to three weeks. Depending on the size of the project, the number of Sprints needed to complete the final product usually ranges from 2 to 12.
As the team completes each Sprint, it produces a new Increment of the product. Each successive Sprint includes a revised Sprint Backlog with additional User Stories that will be added to the product. The end result of each Sprint is an Increment of the product that includes all features present in previous Increments, plus those added during the latest Sprint.
One of the most useful features of Scrum is its ability to help forecast and achieve completion dates for projects. As each Sprint is planned, team members each commit to completion of each task within a certain time frame. Tasks that will take less than a day are forecasted to take 1, 2, 4, or 8 hours. No other time frames are used. Tasks that will take more than a day are forecasted to take 2, 3, 5, or 10 days. Very large items may be forecasted to take 1, 2, 3, or 6 months. Tasks taking longer than a day are generally broken down into smaller tasks, each assigned a smaller time frame for completion. By focusing on small tasks, it is possible to more accurately predict the time the team will need to complete the project.
The Scrum tool that indicates how much time has been spent and how much remains before completion of the project is known as the Burndown Chart. The Burndown Chart can have various designs, but, generally, shows the number of Sprints on the horizontal axis and the number of hours remaining for the next Sprint on the vertical axis. As team members complete each task during a Sprint, the platform software updates the Burndown Chart so that the team knows how many hours remain.
Scrum relies on three roles, and three roles only, in order to function. Let’s look at those now.
The Product Owner
The Product Owner represents the client by proxy to the Scrum team. Their overall job is to ensure that the client’s expectations for the product are communicated to the team, and that tasks are assigned the proper priority during each Sprint. Although the Product Owner has responsibilities and discretion not afforded to other team members, they are not managers and must avoid micromanaging the team.
Among the duties of the Product Owner are:
- communicating client requirements for the product to the team;
- interfacing with Product Management to facilitate project planning and resource allocations;
- defining and prioritizing User Stories;
- defines Story acceptance criteria;
- accepting Stories as completed;
- revising User Stories in accordance with changing needs of the client.
The Product Owner must have excellent planning and communications skills, and must be able to communicate the client’s vision to the team.
The Scrum team is the workforce that designs, develops, and tests the product. The team can also consists of technical writers or other members needed to complete the project according to client expectations.
Team sizes generally range from five to nine people. For large projects, many teams may be involved, each with its own Scrum Master. For such projects, each team may have its own Product Owner (or Feature Owner, if a team is assigned only certain features that they must develop), or one Product Owner may serve more than one team.
The Scrum Master
The Scrum Master is actually more of a Scrum servant. His or her role is to help the team by resolving any problems that prevent the team members from achieving their Sprint goals. He or she also plans meetings, helps motivate team members, and works with the Product Owner to ensure that expectations for each Sprint are realistic.
Although the Scrum Master has limited or no authority, their efforts are crucial to keeping projects on track and on time.
Ceremonies are nothing more than meetings, but they are an important part of Scrum project management. Unlike the waterfall method of project management, meetings for Scrum projects are frequent and short. There are generally four ceremonies that accompany a Scrum project, and we will examine those now.
The Sprint Planning ceremony takes place before each Sprint. During this meeting, the Product Owner presents a prioritized Product Backlog, from which team members will select tasks for inclusion in the upcoming Sprint.
During the Sprint Planning ceremony, team members also forecast how much time and effort will be required to complete each User Story, and, thus, how much time will be required to complete the next Sprint. The Sprint Planning ceremony is usually the longest meeting, and generally lasts no more than an hour per ceremony.
The Daily Scrum, also known as the Daily Standup, is a short fifteen minute face-to-face meeting that usually takes place in the morning. The meeting is called the Standup because members do not sit down. It is an informal gathering in which each member provides a brief account of their progress since the last meeting. They report what they worked on the previous day, what they are going to work on during the current workday, and if they foresee any obstacles to completing their tasks.
Iteration, or Sprint Review
Whereas the Sprint Planning ceremony occurs at the beginning of each Sprint, the Sprint Review occurs at the end of each Sprint. Its purpose, as you might expect, is to allow the team to review the progress made by each team member. During the review, each team member must demonstrate a functional version of the feature they have been assigned. Peer feedback and encouragement are important elements of the review. Sprint Reviews generally take 30 to 60 minutes.
Like the Sprint Review, the Retrospective is facilitated by the Scrum Master and is held at the end of each Iteration of the product, which comes at the end of each Sprint. Unlike the the Sprint Review, the Retrospective focuses on the process rather than the product.
During the Retrospective, each team member answers the following questions:
- What went well during the Sprint?
- What went wrong during the Sprint?
- What can the team do to improve the process?
The Scrum Alliance is the largest association of professionals working in the Agile community. The nonprofit organization states that it exists to inspire, enable, and to guide members as they endeavor to promote the “practices, principles, and values” of Scrum and other Agile methods in the workplace.
Although the organization does not provide training, it directs members to educational resources where training is provided.
In addition to supporting the Agile community through facilitating local group meetings and events, the Alliance provides certification for members working in various Agile methods, including Scrum.
The Scrum Alliance strives to foster greater collaboration, productivity, and success among its members though offering certifications for Scrum practitioners. Current certifications are offered for the following:
- Certified Scrum Product Owner (CSPO)
- Certified Scrum Master (CSM)
- Certified Scrum Developer (CSD)
- Certified Scrum Professional (CSP)
- Certified Scrum Trainer (CST)
- Certified Enterprise Coach (CEC)
- Certified Team Coach (CTC)
Note that only Product Owners, Scrum Masters, and Scrum Developers (team members) are official roles within Scrum. The Professional, Trainer, Enterprise Coach, and Team Coach are each skilled in various methods of Scrum team development, rather than contributing to Scrum projects.
The first step in getting certified is to complete a course of training. The Scrum Alliance website provides an interface for signing up for Scrum certification courses provided by Scrum Alliance authorized trainers around the world.
Hiring and Building a Scrum Team
If your company develops software, you owe it to yourself, your employees, and your clients to adopt Scrum as your framework for project management. But where do you begin?
Ignite can help. We are Scrum experts. Not only do we use Scrum as the framework for developing projects for our clients, but we can guide you through the process of setting up your own Scrum team, from concept to training your team members.
Why not trade in your antiquated, inefficient process of software development and join the community of professional Scrum users? Contact us today for a free consultation.