If you’ve spent any time in digital project management, you’ve likely heard of Scrum methodology.
In fact, a Project Management Institute report found that over half of project managers using an agile framework (that’s 75% of us) use the Scrum process at least some of the time.
A PMI survey showing that a combined total of 55% of organizations “Always”, “Often”, of “Sometimes” use Scrum. (Source: Project Management Institute)
In this article, I’ll go over the origins of the agile Scrum methodology, key Scrum terms, and important things you need to know to apply Scrum in your projects.
Here’s a table of contents to jump to the sections you’re interested in:
- What is Scrum Methodology?
- A Brief History of Scrum
- Scrum vs Agile
- Scrum vs Kanban
- What Are The Scrum Principles
- What Are The 3 Artifacts Of Scrum?
- The Scrum Framework
- Scrum Meetings (a.k.a. Scrum Ceremonies)
- Scrum Software
- Best Scrum Resources
- Scrum Terms
What is Scrum Methodology?
You can define Scrum methodology as a project management approach proposing principles and processes to improve delivery.
Scrum project management fixes the time and cost requirements of projects. Scrum achieves this by using time boxes, backlogs and meetings. It’s a highly adaptive framework that helps complete projects quicker. In Scrum management, projects make progress though sprints. Each sprint produces a deliverable increment.
At its core, Scrum empowers teams to create a healthy tension between delivering the right thing, the right way, as fast as possible.
The goal of Scrum is to improve communication, teamwork and speed of development. Concepts such as Sprints, Scrums, Backlogs and Burndown are all derived from Scrum.
A Brief History of Scrum
- 1986: Hirotaka Takeuchi and Ikujiro Nonaka publish “New New Product Development Game” in the Harvard Business Review.
- 1995: Jeff Sutherland and Ken Schwaber present Scrum at OOPSLA.
- 2001: Sutherland, Schwaber and 15 other developers create the “Manifesto for Agile Development.”
- 2002: Schwaber begins the Scrum Alliance and begins offering Scrum certification.
- 2016: The first fully scalable Scrum is formalized.
The early seeds of Scrum were planted in 1986. Two Japanese business experts, Hirotaka Takeuchi and Ikujiro Nonaka, published the article “New New Product Development Game” in the Harvard Business Review. This was the first mention of a faster and more flexible approach to product development.
However, it would take nine more years before Jeff Sutherland developed Scrum methodology.
In 1995, Sutherland and his work partner, Ken Schwaber, turned Scrum into a formal process. The idea was presented to the Object-oriented planning, systems, languages and applications conference (OOPSLA).
This was Scrum’s first introduction to the outside world.
Then, in 2001, Sutherland, Schwaber and 15 other software developers created the “Manifesto for Agile Software Development.” Not long after the creation of the manifesto, they published the first book on Scrum and Agile development.
The next year, Scwaber founded the Scrum Alliance and began offering certification in specific aspects of Scrum, including a ScrumMaster certification. To date, over 100,000 people have received some form of Scrum certification.
To this day, Scrum is continuing to evolve. In 2016 the first fully scalable Scrum became formalized. These days, Scrum understands the need for distributed teams and two Product Owners. As a result, more organizations are willing to structure their team on the Scrum methodology.
Scrum vs Agile
Put simply, agile is the framework, and Scrum is the approach that uses agile. The two were developed by the same group at the same time so there are significant similarities between the two.
Though it’s popular to view agile and Scrum as competing ideas, it doesn’t give readers an accurate view of the relationship. The difference between Scrum and agile is that Scrum is a plan to implement agile principles. Agile software development with Scrum is one of the most popular approaches to development..
Think of agile as a house and Scrum as a room within the house. Any form of Scrum methodology deployed will also be agile.
However, not all agile approaches follow Scrum methodology. For instance, another popular agile methodology is Kanban.
Scrum vs Kanban
There are other ways to implement Agile, too. For instance, another popular approach is Kanban, which differs from Scrum in that it doesn’t require clearly defined roles, does not execute sprints with a fixed duration time, and is open to workflow changes at all points in development.
What Are The Scrum Principles?
Scrum’s core principles must be followed if it’s to be implemented properly. A few of these are applicable to agile as a whole—such as individuals over processes—and others are unique to the Scrum methodology—such as set roles and duration of Sprints. Here’s a breakdown of core Scrum principles.
1. Individuals and interactions over processes and tools
Firstly it focuses on individuals and interactions over processes and tools. Communication is key, not the processes that run your project. Within Scrum this means the self-organising, cross-functional team.
2. Working software over comprehensive documentation
There is a strong focus on producing shippable products quickly, rather than spending a lot of time writing down requirements. In Scrum software development, time-boxed sprints of work are run with a shippable increment produced at the end of each sprint.
3. Customer collaboration over contract negotiation
Agile values specify client or customer collaboration, working with the client at all points with them being heavily involved throughout the process. Scrum has consistent, and regular, client involvement
4. Responding to change over following a plan
Rather than seeing changes as the enemy, being in a position to see change as a good thing and being responsive to it is core to the Agile framework. Scrum has constantly evolving requirements, and change is embraced.
What Are The 3 Artifacts Of Scrum?
Scrum artifacts communicate key information that the Scrum team needs to be aware of during product development.
1. Product Backlog
Product backlog lists all the features, functions, and requirements that must be made to the product. It’s common for a product’s requirements to change over the course of development, either to reflect business needs or market trends. The product backlog will constantly update to reflect such changes.
2. Product Backlog Item
These are the items that make up a product backlog. They detail the changes that need to be made and the desired outcome. One way to express the desired outcome in a way the Development Team will understand is through ‘user stories’ a simple sentence that explains what a certain business or user is looking for in the product.
User stories are structured like this: “As a [blank] I want to [blank] so that I can [blank].”
3. Sprint Backlog
The product backlog items that have been selected for a sprint. This will also include a plan for producing an Increment at the end of the sprint. The sprint backlog defines the work that the Development Team will perform during the next sprint and the items required to produce an increment that meets the definition of done.
The Scrum Framework
Within the Scrum methodology are clearly defined roles.
These roles help set the Scrum model apart from similar Agile methods like Kanban.
The Scrum environment promotes using small, flexible teams of no more than 9 people who work through the product backlog.
1. Scrum Development Team
A Scrum Development Team is a group of professionals responsible for delivering a releasable increment of “Done” at the end of each Sprint.
Development Teams are unique in the following ways:
- Development teams are self-organizing. Nobody within the Scrum team (not even the Scrum master) is allowed to tell them how to turn the Product Backlog into Increments.
- They’re cross-functional. All members must have the skills required to create an Increment.
- They are responsible for successes and failures as a team. It doesn’t matter if one member made a mistake that caused the team to not have an Increment at the end of a sprint, the Development Team accepts responsibility as a whole.
2. Scrum Master
The Scrum Master is responsible for leading the Scrum Team. They make sure everyone has a firm understanding of Scrum principles and offer guidance and teaching when it’s necessary.
The Scrum master leads the Scrum team through the daily Scrum. They’ll often ask three questions:
- What did you do yesterday?
- What will you do tomorrow?
- What obstacles are in your way?
The Scrum master is not the ultimate leader of a Scrum team, however. They are not directly responsible for outcomes. The whole team as a whole must accept responsibility for the end product.
The Scrum master will also work with the Product Owner to make sure the project is on track. They’ll do tasks such as:
- Guaranteeing that the Scrum goals are understood by everyone.
- Optimizing Product Backlog Management.
- Organizing Scrum events
- Helping the Scrum team understand the need to concise product backlog items.
The Scrum master’s job is to keep everyone focused and pushing towards the same goal. They want to remove obstacles, prevent against unnecessary distraction, and help the team make progress day after day. Even though the result of the Scrum ultimately rests on the entire team, Scrum masters often feel a lot of pressure to succeed in the position.
3. Product Owner
The Product owner represents the business or customer base. They are there to ensure the other members of the Scrum team don’t forget the purpose of the sprint. Because of the wide variety of potential business users and customers, the Product Owner must have a strong understanding of the users needs.
Each sprint begins with the product owner prioritizing the requirements and features of the product to the Development Team. Their job is to answer any questions the Development Team may have regarding specifications and requirements. The product owner is not involved with development.
Scrum Meetings (a.k.a. Scrum Ceremonies)
There are 4 main kinds of Scrum meetings or Scrum ceremonies:
Certain types of Scrum meetings will take place during specific times in the development process. These are also known as the Scrum Ceremonies. For more information, you can read our guide to scrum ceremonies.
1. Daily Scrum
Each day, a daily Scrum meeting will take place where team members discuss progress they’ve made and problems they’ve faced.
Scrum meetings take place every day during a sprint. They should be no longer than fifteen minutes and should be for the sole purpose of clarifying any challenges that the development team faced in the previous day.
They are held every day to prevent problems piling up in the background. Any questions or concerns should be raised at the daily Scrum meeting.
Want to make sure you’re running the best daily Scrum possible? Read our guide on How-To Run A More Effective Daily Scrum.
2. Sprint Planning Meeting
During a sprint planning meeting, the team agrees upon the series of product backlog items they will complete in the upcoming sprint.
For every one week of a sprint, an hour is set aside for sprint planning. The sprint planning meeting takes place before a sprint begins so if the upcoming sprint is for 4 weeks, the team will set aside four hours for the meeting.
The most important part of a sprint planning meeting is the preparation that must be done before the meeting starts.
Read our full guide on How To Run a Sprint Planning Meeting.
Which and how many items from the product backlog will be completed depends on the team’s commitment and velocity (the speed at which the Development Team can create Increments). If your sprint planning with a new team, it’s best not to calculate based on expected velocity until you’ve done a few sprints with the team.
1. Sprint Review Meeting
The sprint review meeting takes place at the end of a sprint with the expressed purpose of looking over the progress made. During a sprint review the Scrum Master and product owner will see if the results match the expectations set at the sprint planning meeting. Here, the product owner will verify that the Increment of work meets the definition of done.
2. Sprint Retrospective Meeting
A sprint retrospective meeting allows your team to look back on past events and situations. According to the Scrum Guide, the sprint retrospective is an “opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” Makes sense, especially since the focus of agile development is continuous improvement. In order to get better, you have to know which sword to sharpen.
The retrospective should create a safe space for people to share their honest feedback on what’s going well, what could be improved, and generate a discussion around things that should change next time around – with actionable items documented.
Read our full guide on how to run a great sprint retrospective.
Scrum tools aren’t just for agile software development teams, even though that’s where Scrum originated. The Scrum framework can be used in many production settings—from marketing agencies to construction firms.
Here are some of the best project management software with items like backlogs and sprint planning features that help you follow the Scrum methodology.
Get in-depth reviews of these tools—along with screenshots, scores, and pricing info—in my Scrum software review.
- Vivify Scrum
Best Scrum Resources
- Scrum: A professionally recognized organization that offers training and official certification.
- Scrum Inc : Founded by Jeff Sutherland, the co-creator of Scrum, who regularly updates the blog. They offer training and certification.
- Scrum Alliance: A nonprofit that teaches individuals of all experience levels about Scrum.
- Scrum Guides: The official Scrum Body of Knowledge. Written by the co-creators of Scrum, Ken Schwaber and Jeff Sutherland.
- Scrum With Style: Australia’s leading Scrum training service. Offers coaching and certification.
- Atlassian: Australian enterprise software company that provides guides about Agile methodology, including Scrum.
- Visual Paradigm Scrum Guides: A large database of articles on all things Scrum, from basic definitions to problem solving specific problems.
To the uninitiated, Scrum may sound intimidating. There are some terms that you’ve likely never heard of before. And that’s exactly what I’m here for. Here’s a list of Scrum terms you can refer back to at any point:
- Agile: The framework within which the Scrum methodology was developed. Promotes adaptation and flexibility over rigid structure.
- Burn-down Chart: A chart showing the amount of work that remains in the product backlog.
- Burn-Up Chart: A chart showing the amount of work that has been completed from the product backlog.
- Coherent: Quality of relationship between Product backlog items. If enough items are coherent together they may be worth considering as a whole, and should be mentioned when discussing the next Sprint Goal.
- Daily Scrum: A meeting held everyday, where fifteen minutes is set aside to structure the upcoming day of work.
- Definition of Done: The expectation that an Increment must meet to be considered releasable.
- Development Team: Team within the Scrum Team that manaes, organizes and does the development work required to create in Increment.
- Empiricism: Process control which states that only the past is certain. Allows for maximum flexibility within the agile framework.
- Engineering Standards: Set of standard shared across teams to ensure Increments.
- Forecast of Functionality: The set of increments taken from the product backlog that the Development Team views as possible to complete in a sprint.
- Increment: A piece of software that can be added to other increments. Put together, enough increments make a product.
- Product Backlog: A list (typically ordered) of the work that must be done to create a product.
- Product Owner: Team member in Scrum tasked with maximizing a product’s value.
- Scrum Board: An easy way to visualize the information shared between the Scrum Team.
- Scrum Guide: The original definition of Scrum. The guide details Scrum’s roles, events, artifacts and rules.
- Scrum Master: Responsible for leading the Scrum Team. Makes sure everyone has a firm understanding of Scrum principles. Offers guidance and teaching when necessary.
- Scrum Values: The core values that drive the Scrum framework. These are: commitment, focus, openness, respect and courage.
- Self-organization: A core principle of Scrum which states that teams must internally organize their work without interference from outside teams.
- Sprint: A time-frame of one month or less where Scrum events are carried out. Sprints are carried out back to back. There are no breaks between them.
- Sprint Goal: The purpose of the current sprint.
- Sprint retrospective: A meeting, three hours or less, where the sprint team comes together and discusses any improvements that should be implemented for the next Sprint.
- Sprint Review: A meeting, four hours or less, that represents the end of a sprint. Work is reviewed and the stakeholders inspect the Increment to ensure it meets the definition of done.
- Stakeholder: Person outside of the Scrum Team. Provides an outside perspective and is actively involved in Sprint Reviews.
What Do You Think?
Although Scrum has been around for a long time, it’s always evolving. What are some things you learned about Scrum? Or something you would add to improve the methodology? Let me know in the comments