What is SCRUM and why you would want to implement it

SCRUM offers software development teams the advantages of agile methodologies while also adding value thanks to its specific principles and rules for organizing project work. This post is about the what and why; the following post will describe how to implement it in 10 steps.

If you haven’t learned how to SCRUM, you will want to soon. Zippia reports that, in the software development business, SCRUM is the most popular Agile framework, being used at 61% of the companies surveyed. Companies need to quickly adapt to the changing economic and legal environment as a project continues, so the concept of Agile software development was codified in the Agile Manifesto in 2001. The SCRUM methodology, developed in 1995, is now considered an example of Agile.

Any Agile framework is a way to organize the work on a project, so that you can

• quickly respond to external and internal changes,
• incrementally deliver products,
• increase a team’s motivation,
• improve communication between team members, and
• monitor progress effectively.

In SCRUM, product development is divided into iterations known as Sprints. Each Sprint should not last longer than one month, enough time for the team to deliver working functionality. Naturally, the first task is to draw up a list of user requirements. The requirements are expressed in the form of user stories. Each user story defines a specific product feature and its priority level, and is attributed to the Product Owner. These stories will ultimately form the product backlog, and the backlog is the starting point for organizing how the work will flow.

Why implement SCRUM?

One of the main challenges encountered in project management is planning and then executing the plan. Experience and research show that preparing a comprehensive plan that includes the schedule and a cost estimate for complex, abstract initiatives is very difficult if not impossible. In practice, managers are forced to build a rough model and then base their plans on it. This is the only way to work without a complete data set. Such an approach also focuses efforts on executing plans instead of delivering business value. What’s worse is that time may reveal numerous imperfections, and classic methodologies make it extremely difficult to eliminate them on the fly.

SCRUM is a completely different way of thinking about how to organize work. Experience in planning and reacting to emerging situations are at the forefront. Short-term planning and specific goals for each Sprint move the team toward the final product. The goals must be specific, measurable, achievable, relevant, and time-defined: SMART.

Every Sprint must end with a measurable effect and a presentation of achievements. This makes it easy to verify progress. SCRUM teams continually adjust the production process according to the current conditions because the team keeps the information about the project’s progress up to date.

The client’s perspective versus the supplier’s perspective

When the client’s project is managed with SCRUM, they always know how much progress is being made, they can supervise the budget, and they can adjust the project according to new information. The client is not only the recipient of the product but is in fact an active project participant who has a direct impact on it. The client may appoint a representative to the team to play the role of Product Owner. This is a powerful role with influence on how the Development Team delivers on the requirements and refines the result.

The SCRUM framework describes how the Product Owner oversees and participates in the team’s work. As a result, the client always knows what stage the project is at, who is performing the tasks, how much time was spent on the work, how many requirements have already been met, and how many are still waiting in the backlog. The client has full control over time and the budget, which means they get to adjust the team’s priorities according to present conditions. 

How does the SCRUM process answer “what, when, and how much?”

…You know—the usual questions.

What can make a client reluctant to contract a project to a SCRUM-managed team is that it can seem difficult to fit a project’s top-down definitions of cost and delivery time into a SCRUM framework. But since SCRUM can help smooth project delivery and reduce the risks directly associated with the traditional “waterfall approach,” it’s worth convincing any skeptical executives.

That doesn’t mean ignoring the question of cost and delivery time. To consider whether to manage a project with SCRUM, a change of perspective is needed. The questions “What, when and how much?” are replaced with “What value can I deliver to my company in the shortest possible time?” SCRUM lets the team plan the work so that after the first Sprint, in 2 to 4 weeks’ time, the client gets a working part of the solution, such as a selected module or process. In practical terms, the client gets to review the product with every Sprint and adjust their expectations for further work. It’s easier and more accurate to make these adjustments when you see working software than when trying to get an overall view from complex documentation.

Managing a project with SCRUM helps the supplier put together the right size team that has the right set of skills to perform the necessary tasks, over a certain number of Sprints depending on how many tasks there will be and how much time is made available.

In this context, the questions what, when, and how much are answered this way:

• The What is “a solution that meets the client’s initial requirements.” The project team is sized accordingly, and if the client has reasons to make changes to the list of tasks, that’s perfectly acceptable. The result is a product that meets the client’s real needs and brings real value to their organization.
• The When is “after each Sprint.” As mentioned before, a Sprint takes 2 to 4 weeks to deliver specific functionalities that are ready for release. The Product Owner—the client—has full discretion whether the existing set of deliverables meets expectations and if the project is complete.
• The How much is the number of planned Sprints multiplied by the contracted fee per Sprint. The fee is calculated by multiplying the number of person-days (PD) in a Sprint by each team member’s employment rate.

What SCRUM looks like in practice

If the SCRUM process is so uncomplicated, easy to implement and beneficial for the client, then why isn’t it ubiquitous? Simply put, it requires a shift in mindset and some real-life practice. This is why SCRUM masters are in high demand—they have the experience necessary to effectively lead a team through the process. In time, all of the team members will have enough experience to lead a SCRUM without needing a SCRUM master.

SCRUM consists of Pillars, Roles, Artifacts and Events.

Pillars

• Transparency ensures that everything related to the tasks is visible, accessible, and equally understood by everyone on the team. The visibility and accessibility also extends to stakeholders who are not on the team.
• Review ensures that the Artifacts (see below) and progress are regularly reviewed so that if the project is taking a turn away from meeting expectations, such a change in direction is noticed. This is not to say that a change in direction is always bad! The review allows the stakeholders to decide if the new direction opens up new opportunities or if the process risks going down the proverbial rabbit hole.
• Adaptation is built into the SCRUM framework, avoiding the sunk-cost trap of the waterfall framework. If the review process reveals that the SCRUM team is headed in a different direction, the Product Owner can adapt the process accordingly.

Roles

The SCRUM team consists of the following:

• The Product Owner makes the decisions about product development and how the Development Team’s time is organized, all with the aim of building as much value as possible. The client should choose someone with a detailed understanding of the business needs potentially answered by the developed product, and who knows what the stakeholders’ goals and expectations are for the shape of the final product. The product owner receives and accepts the work done by the Development Team.
• The SCRUM Master has a deep understanding of the SCRUM rules and is responsible for putting them into practice. This is a facilitator role that supports the team by identifying and removing any obstacles.
• The Development Team doesn’t just execute tasks. The team members organize themselves according to the skills they need to produce a product and plan the tasks in order to achieve their goals, which are initially provided by the Product Owner.

Artifacts

This is an interesting choice of term, isn’t it? SCRUM artifacts are not leftovers or clues, but rather tools produced on the way toward a goal.

• The Product Backlog consists of so-called “user stories,” which are descriptions of product features, i.e., the expected functions that the team should create. This list of “stories” is used to inform the various stakeholders what tasks and what skills will be necessary to execute the work. The product backlog can—and should—be updated as business needs change and opportunities arise. Everyone needs this backlog to have a clear idea of how much progress has been made and how many things need to be done.
• The Sprint Backlog is the subset of stories that will be the focus—the goal—of a single Sprint. The product owner and the development team, mediated by the SCRUM master, collaborate closely to make this list. It serves as the basis for the development team to decide what tasks they will complete in order to reach the goal.
• The Increment is the product of one Sprint. It is a completed, tested, integrated, and functional step toward the final product, so the Product Owner can see and evaluate the result.

Events

• A Sprint planning meeting, where the SCRUM Team works together to decide what they will complete in the upcoming Sprint.
• The Daily SCRUM is a daily meeting lasting no more than 15 minutes to “synchronize.” Team members talk about what they completed the previous day, what they are going to do on that day, and if they see any possible obstacles in the way of the day’s tasks.
• At the Sprint review, SCRUM teams present what they completed in the Sprint. The client participates in this meeting and presentation, which is an opportunity to ask questions, critique the results, make suggestions for future Sprints, and express appreciation for the completed work.
• The Sprint retrospective is the least formal meeting, where the team members discuss what they might change in order to improve the process.

All four of these elements make up the SCRUM cycle, as shown in Fig. 1: