An Easy-To-Follow Scrum Overview: What Is It and How Does It Work?

Thus, the demand for Scrum Masters is up 104% from previous years. What’ more, a Scrum Master’s projected career advancement score is 8 out of 10.

Scrum applies to virtually any organization. Scrum methods help companies get their products to market faster than ever before.

Scrum’s Beginnings

The Scrum framework originated in 1995. Jeff Sutherland and Ken Schwaber created the framework.  In 1995, they presented it to the Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) conference, which was held in Austin, Texas.  Soon after, they formalized their methodology by publishing a paper called “SCRUM Software Development Process.”

What is Scrum? How does support the Agile framework? Here is your Scrum overview, covering everything from the framework’s history to terminology and process descriptions.

Origin of the Term Scrum

The name Scrum came from an earlier paper written by management experts Hirotaka Takeuchi and Ikujiro Nonaka. It was published in 1986 and was titled “The New New Product Development Game.”  Takeuchi and Nonaka borrowed the word scrum from the game of rugby. The authors wanted to stress the importance of team collaboration to ensure a project’s success.  The research in the paper highlighted how developing intricate projects required small, self-organizing teams, which receive objectives rather than tasks.

The teams that excel are the ones given a balance of direction and autonomy to forge their own tactics towards meeting those objectives.

Applying Scrum to Software Development

Sutherland and Schwaber’s Scrum framework was inspired by Takeuchi and Nonaka’s research on adaptive practices, applying the concepts to software development. Along the way, Professor Babatunde A. Ogunnaike Tunde joined the collaboration.  Tunde was a process control research engineer. His role was to explore how Scrum worked with other methodologies.

Tunde found that some methodologies like Waterfall and other traditional processes didn’t align well with the Scrum framework. Professor Tunde deduced that an empirical approach worked best with Scrum. Empiricism is one of the key tenets in the Scrum framework. The three pillars of Empiricism consist of Transparency, Inspection, and Adaptation.

The Alliances

By 2001, Sutherland and Schwaber, along with fifteen other software development leaders, created the Manifesto for Agile Software Development.  Later in 2001, the Agile Alliance was formed. Ken Schwaber had a significant hand in the early days of these organizations serving as a founder and assuming the role of the first chairman of Agile Alliance.

The next year, Schwaber was instrumental in the founding of Scrum Alliance. Not long after, Scrum Alliance, with Schwaber’s leadership, established the Certified Scrum accreditation program.

Scrum.org

The Scrum community continued its evolution in 2009. Schwaber left the Scrum Alliance after having disagreements with the board about topics centering around certifications, assessments, and a developer program. He started Scrum.org, which offers the Professional Scrum series.

Over the years, Scrum has grown in popularity, taking on a global role in project management. Project managers around the world have copies of the Scrum Guide, which was published in 2010. The guide was updated in 2011, 2013, and 2017.

Today, it’s one of the most-used Agile frameworks in project management. The framework has grown to work with large teams, no longer limited to small team structures. Several approaches to scaling Scrum have been developed over the years. The original scaling approach is called Scrum of Scrums, it scales the technique to large groups. Other approaches, with names like SAFe, LeSS, Nexus, Lean and Agile Program Management, and DaD have been developed by various methodologists in an attempt to scale Scrum across multiple Scrum teams.

Scrum in Agile

Scrum is a part of the overarching Agile framework. However, it is certainly not the only part. If you think of Agile as a large tent, Scrum is an important pillar.

Agile does not prescribe steps to follow. The Scrum framework provides a lightweight framework which can be applied to your project. In addition to Scrum, there are other frameworks, like Feature Driven Development or Extreme Programming, that can be applied as well.

Scrum is simple, and the autonomy is desirable to many. Organizations can also use Scrum as an entry point to additional complimentary Agile practices. Scrum is not limited to use with only software. It has proven beneficial when applied to projects and business process outside of software development such as HR, Accounting, Sales, User Experience, and managing companies.

Scrum Overview: Scrum Terminology

Before diving into the Scrum overview, let’s start with an explanation of some of the Scrum terms that you’ll see. This part of the Scrum overview will detail some of Scrum’s core concepts.

Sprint

The Sprint is an event that acts as a container for all the other events in the Scrum framework. The Sprint is usually time-boxed between two to four weeks in duration, with the duration established at the beginning of the Sprint. Each Sprint immediately follows the last Sprint.

Time-Box

A time-box is the maximum duration of an event. In the Scrum framework, all events are time-boxed to ensure the objectives of the meeting are achieved.

Product Owner

The Product Owner is the key actor for the project. He or she represents stakeholders (users, customers, and others) involved in the process. Typically, the product owner comes from a product management or marketing area. They may also have been or are currently a key stakeholder. 

There is only one Product Owner responsible for managing the product backlog.  The Product Owner’s main responsibility is to be the Value Maximizer for the Scrum team. The Product Owner fulfills that responsibility by managing the product backlog and its content. Managing the Product Backlog consists of:

• Items that are clearly expressed. 
• Ensuring the items in the product backlog are ordered to maximize value and achieve the goals of the Product Owner.
• Ensuring transparency and visibility of the Product Backlog and the items it contains.
• Working with the Development team to clarify and help in understanding the items in the backlog.

While the Product Owner is responsible, others may assist in the development and maintenance of the items in the backlog.

Scrum Master

The Scrum Master ensures that the team maximizes its productivity. The Scrum Master serves as an evangelist, helping the team apply the Scrum framework. The Scrum Master is a servant-leader, serving the Product Owner, Development Team, and the Organization. As a servant leader, the Scrum Master can provide the following services:

1. Facilitating Scrum events as required
2. Leading and coaching in the adoption of Scrum and empiricism
3. Assist in the creation of high-value products
4. Assist in the planning and ordering of the items in the Product Backlog
5. Removing impediments to the Development team
6. Buffers the team from external distractions

The Scrum Master is often the glue that initially holds teams together while coaching and mentoring the Scrum team with the goal of the team becoming a high performing team.

Development Team

In the Scrum framework, the Development team should have all the skills required to complete the work to be undertaken. Optimally, a team will consist of between three and nine people, excluding the Scrum Master and the Product Owner. Projects that use Scrum can scale up to include teams into the hundreds. However, Scrum can also feature one-person teams.

Traditionally, software teams would consist of roles with titles like designer, programmer, architect, or tester. Scrum doesn’t recognize those titles. Scrum embraces the team concept, with everyone working together to complete the work, which they commit to completing as a group. Over time, as Development teams work together to deliver value, the teams tend to develop a deep camaraderie and trust for one another.

A feeling of “We’re in this together” begins to permeate through the team, uniting the team as they move forward.

Product Backlog

The product backlog is an ordered list of all the desired product features or changes to the product. Building the Product Backlog usually begins with the Product Owner creating a list of features that they wish to be included in the Product. The Product Owner works with the Development team to order the items on the Product Backlog. The Product Backlog is dynamic and evolves over time as more is learned about the product, technology, risk, the use of the product by customers, regulations, and the business domain.

Items in the Product Backlog can include features, functions, requirements, non-functional requirements, technical debt, defects or bugs, and spikes. The items most likely to be worked on soon should be in a ready state and can be completed within the duration of a Sprint.

One practice towards the Product Backlog that can considerably help a Scrum team is to conduct Backlog Refinement meetings. The purpose of a Backlog Refinement meeting is for the Product Owner and the Development team to review the items ordered at the top of the Product Backlog to gather a better understanding, gain additional clarity, estimate the complexity, and as required, split items into smaller items that can be understood and consumed by the Scrum team in one sprint.

Sprint Backlog

The Sprint Backlog contains the work plan for the team and is the list of tasks the team needs to complete during a sprint. The Development team is the owner of the Sprint Backlog. As the owner, the Development team is responsible for maintaining the Sprint Backlog throughout the Sprint.

Definition of Done

The Definition of Done is a checklist of all the activities, tasks, and conditions that must be completed for a piece of work to be considered complete. In organizations where only one Scrum Team exists, the Scrum Team should create and maintain the Definition of Done. When multiple Scrum teams exist in an organization, an enterprise Definition of Done should be created which becomes the minimum standard. Each team can then add additional requirements to the Definition of Done to meet their unique needs.

Sprint Planning Meeting

The team holds a Sprint Planning meeting at the beginning of each sprint. At this meeting, the product owner reviews the top items on the product backlog. Scrum team members seek further clarification on the top items and select the work they feel they can forecast completing during the sprint. Those product backlog items are moved into the Sprint Backlog. The Development team starts to identify the tasks and activities that are required to complete the forecasted work.

The Development team moves the requirements and the tasks identified from the product backlog to a separate backlog that is maintained by the Development Team. The Development Team’s backlog is referred to as the Sprint Backlog. It contains the list tasks needed to complete the product backlog items the team selected to be completed in the sprint.

The Scrum team collaboratively should identify the goal of the Sprint. A goal for the Sprint provides a measure for the Scrum Team to apply against everything they do to determine what they do and how they do it.

Daily Scrum

The Daily Scrum is a brief meeting with a timebox of 15 minutes that occurs every day at the same time and place during the sprint. The meeting is not a problem solving or status meeting. The purpose of the Daily Scrum is for the Development team to inspect the work completed and remaining and adapting the work plan contained in the Sprint Backlog to achieve the Sprint Goal. Many teams will use the framework of asking three questions:

1. What was completed yesterday?
2. What will be worked on today?
3. Is there anything in your way to completing the work? 

It sets the context for the day’s work, which helps the team stay focused. All team members are must attend the daily scrum. Others outside the Scrum Team may attend to observe, but should not participate.

Sprint Review Meeting

At the end of the sprint, the Scrum team and interested stakeholders inspect the work that was accomplished during the Sprint at the Sprint Review meeting. For many, the Sprint Review is an informal demonstration of new features, celebrating successes, and inspecting failures. By informal, the team should demonstrate working software, and avoid the use of PowerPoint presentations. The idea is that presentation itself shouldn’t be a task, thus distracting the team member from the process.

However, the Sprint Review is also an opportunity for the Scrum Team to interact with stakeholders gathering feedback and insights into:

1. The value provided by the work delivered
2. The future of the product/project
3. Insights into the business domain
4. Insights into market changes
5. New/changing regulatory requirements

Sprint Retrospective

Another event that occurs at the end of a sprint is the sprint retrospective. This is a meeting for the entire team (product owner and Scrum Master included) to reflect on how well Sprint went and how the Scrum framework is working for them. Topics for the team to consider for improvement might include:

1. How the sprint went with regards to people, relationships, process, and tools
2. Evaluate what worked and what didn’t 
3. For what didn’t work, identify ways that might eliminate problems
4. Develop a plan for implementing improvements

Attendance at the meeting is limited to members of the Scrum team. Outsiders can influence the mood of the Scrum Team members, impeding and reducing transparency. The Sprint Retrospective is for the team.

As a key part of a continuous improvement process, the Sprint Retrospective is critical to a team becoming high performing. A well-run Sprint Retrospective identifies opportunities for a team to improve. Acting on those opportunities, a team will continuously improve to achieve a higher performance regardless of where they start.

The Scrum Framework

By design, the Scrum framework is simple, easy to learn, yet hard to master. Scrum is a framework and not a methodology.  Yet, Scrum often erroneously gets classified as a methodology by many.

Scrum is made up of five events, three roles, and three artifacts. A small number of rules tie it all together. The Scrum events are:

Sprint Planning

• Sprint
• Daily Scrum
• Sprint Planning
• Sprint Retrospective

The roles in Scrum are:

• Product Owner
• Scrum Master
• The Development Team

The artifacts in Scrum:

• Product Backlog
• Sprint Backlog
• Product Increment

The key to Scrum is the Sprint. The Sprint is a container event that houses all the other events. At the start of the Sprint, the Scrum Team conducts the Sprint Planning event. The team consults the product backlog, forecasts which of the highest priority items can be completed during the Sprint, and then determines how to complete each one. The product backlog items are moved from the Product Backlog into the Sprint Backlog. The team should keep the plan collaborative and ask the product owner and stakeholders questions as needed.

Immediately after the Sprint Planning event, the team starts to work. The Sprint itself is time-boxed between two and four weeks. During the sprint, the Development team should refrain from making changes that could hinder them from completing the objectives in time. The team can and should revise scope as needed, consulting with the Product Owner as required.

As the Development team is working, it has a daily event called the Daily Scrum. The purpose of the Daily Scrum is for the Development team to inspect the progress made by inspecting the Sprint Backlog. Any changes that need to be made to Sprint Backlog are usually done immediately after the Daily Scrum. The team should avoid attempting to solve problems during the Daily Scrum. Problem-solving in the during the Daily Scrum can extend the duration by derailing the meeting, as well as taking away from the purpose of the event.

By the end of the sprint, the Scrum Team strives to complete all the work that the team committed to during Sprint Planning. Work is considered complete when it meets the Definition of Done. All testing, documentation, and reviews should be completed. Many teams struggle with completing regression tests. While teams can’t rerun every process in the sprint, they can be selective taking a risk-based approach.

The last day of the Sprint, the Scrum team conducts a Sprint Review and Sprint Retrospective. The Sprint Review is an opportunity for the Scrum Team and the stakeholders to review the work completed in the Potentially Shippable Increment, review what is coming up in the future sprints, and to look at other factors, such as market and regulatory changes, that may influence future sprints.

The Sprint Retrospective is usually the last activity of the Sprint. The purpose of the Sprint Retrospective is to provide an opportunity for the Scrum team to continuously improve by inspecting the Sprint and its outcomes, identifying improvements that can be made, and adapting processes as required. The Scrum team members should be the only attendees of the Sprint Retrospective. At the discretion of the Scrum team, the Scrum team has the ability to invite others who may be able to contribute to the meeting. Any improvements identified should be included in future sprints to be implemented to sustain a continuous improvement cycle.

Doing so allows the team the opportunity to collect data. This can be expensive, so efficiency is key. When possible, teams use automated Scrum technology to save time and costs.

The Scrum cycle begins again with the next backlog item. Repeat the steps and modify the process as you learn and go. You and your team will continue to refine your processes with each new sprint.

Scrum Is an Adaptable Framework

As this Scrum overview describes, Scrum is a formidable, adaptable framework for getting work done.

At Scrum’s core are five values. those values are Focus, Openness, Courage, Commitment, and Respect.

Scrum’s adaptability is one of Scrum’s biggest advantages. At the beginning of every Sprint, new work is selected from the top of the ordered backlog, allowing for the direction of the product or project to change. Combining the adaptability of Scrum with the power of Scrum’s Continuous Improvement focus can enable a team to transition from a low-performing team to a high-performing team quickly.

Summary

Scrum is one of a number of frameworks under the Agile umbrella. Scrum is an adaptable, incremental framework that can deliver work in short duration time-boxes (Sprint) while providing transparency to the organization as to the status and progress of the work completed.

If you have additional questions about Scrum or how it fits within Agile, please contact us.