Explore

What is Scrum? Methodology, process, & framework

A deep-dive into one of the most popular project management frameworks and how to adopt Scrum into your project management processes.

The Scrum methodology is one of the most popular frameworks for project managers around the world. Used in businesses of all sizes from global organizations to small tech startups, Scrum is the most popular Agile methodology for project managers.

But what is Scrum and how do you put it to practice? Learn about the Scrum methodology, what it is, and get details about its processes and procedures. We’ll also compare Scrum to other project methodologies like waterfall and Kanban.

What is the Scrum methodology?

The Scrum methodology was created by Japanese management experts Hirotaka Takeuchi and Ikujiro Nonaka. In 1986, they urged project managers to shift away from the traditional, sequential method of developing new products to a flexible, faster product development approach that’s more team-driven.

Inspired by rugby, the name brings to mind a team putting their heads together in a scrum to address complicated problems as a team.

Scrum is an Agile project management framework to help organize cross-functional teams and break work into manageable pieces within a prescribed timeframe (called a project sprint). During a sprint, the team produces a shippable product and conducts a team retrospective to optimize the process to carry into the next sprint.

The Scrum methodology encourages teams to:

Learn through experiences and continuous feedback

Break down a massive task into smaller, more manageable chunks

Be self-directed and have the freedom to approach a problem in their preferred method

Work fluidly across multiple functions

Focus on prioritizing the right tasks to be done

Who uses the Scrum methodology?

The Scrum methodology is prevalent in software development teams. However, it’s flexible enough to be applied to any form of teamwork. Multiple business functions like marketing, HR, and finance, across industries like hospitality, construction, consultancies, and financial services use Scrum to drive their projects.

Agile framework vs. Scrum framework: What's the difference?

Although the Agile framework and Scrum framework share many similarities, they are not interchangeable.

The Agile framework is a set of high-level guiding principles, and the Scrum methodology is a framework that puts Agile’s principles into practice.

Imagine the Agile framework is like the team’s compass, describing the right direction to go. It is the team’s primary guiding principle. The Scrum framework is the team’s map. It shows where to go in a more practical, applied manner. Both the compass and the map work together to get the team to their destination (a successful project delivery and completion).

Other differences between Agile framework and Scrum framework:

When items are delivered: In Scrum, project deliverables are given at the end of a project sprint. In Agile, deliverables are provided once the project is complete.

The roles of the team: A Scrum project team includes specific functions like the Scrum master and product owner. Agile involves members from various cross-functional teams.

Why is the Scrum methodology so popular?

Scrum ensures a win-win scenario for stakeholders, end-users, and the scrum team. Scrum thrives on frequent iterations and continuous adaptation to feedback and change. This helps development teams quickly deliver something that the end-customer uses, while fast development cycles ensure feedback from end-customers and critical stakeholders.

Scrum breaks down complex projects into bite-sized chunks. When we see a big goal, we often feel overwhelmed and are hesitant to progress. Scrum breaks down complex projects into smaller, workable chunks, ensuring the team stays focused and motivated while completing work faster.

Scrum boosts morale and encourages self-ownership. Scrum taps into intrinsic human motivators and recognizes the human need for achievement, positive feedback, and self-ownership of assigned work within a robust team environment. A Scrum team does not have a traditional boss to report to. They organize tasks within themselves in the most efficient way possible.

Six Scrum values & principles

Successful implementation of the Scum methodology is often determined by how well a team embodies a set of six values and principles.

1. Empirical process

Empiricism means working in a fact-based, experience-based, and evidence-based manner.

Progress in Scrum is based on observations of reality. The methodology focuses on deliverable work products and adjusting to conditions on the ground.

The empirical process follows three core principles:

⁠

Image source:

Scrum.org⁠

⁠

Transparency: Everyone involved, including customers, project team members, and critical stakeholders, know what is going on. Teams avoid hidden agendas or disguising facts.

Inspection: The Scrum team showcases work done at the end of each sprint during sprint reviews to the customer and reviews progress internally. The team checks its work as it is completed.

Adaptation: The Scrum team practices continuous improvement by asking whether they have improved today compared to yesterday. Practicing continuous improvement eventually translates into tangible business results like faster time to market and improved customer satisfaction.

2. Self-organization

Scrum teams work independently and self-organize. Once they understand the goal of the sprint and the product backlog items to focus on, the team decides on the best internal working style to meet that goal. The team chooses who does what, when to do it, and how to do it with minimal involvement from people outside the team. Teammates are accountable as one team.

The Scrum Guide highlights that if you want
Scrum to succeed⁠
, the Scrum Team needs to have the freedom to take ownership of how, what, and when the work gets done.

3. Cross-functional collaboration

Scrum teams thrive on cross-functional collaboration. They are self-contained and have the required domain knowledge and skills without relying on others outside the immediate team. Focusing on cross-functional collaboration prevents the formation of silos and creates a foundation of trust and transparency within the team, leading to better work outcomes.

Each Scrum team includes:

Product owner

Scrum master

A varying number of developers (individual contributors) with their area of specialty depending on the complexity of the project

4. Prioritization

Scrum teams relentlessly prioritize tasks in order of importance to help them deliver the most business value in the fastest time possible.

While prioritizing tasks in the product backlog, the team looks at three factors:

The overall value delivered by this task

Any associated risks or uncertainties

Any dependencies that arise out of implementation

5. Time-boxing

Time-boxing is the practice of allocating a fixed, maximum time for an activity. A time-box defines and limits the amount of time given to ambiguous or open-ended tasks for the whole team.

Practicing time boxing effectively helps teams:

Provide a clear definition of ‘done’ for ambiguous tasks

Create a time constraint on tasks, encouraging teams to get work done more effectively. Each sprint or iteration should produce a work product that can be demonstrated to a customer

Define the scope for all Scrum events. For example, the length of the sprint is time-boxed to 1-4 weeks, depending on the organization. Sprint planning sessions should take no more than two hours.

6. Iterative process

Scrum teams follow an iterative development process of their deliverables. It breaks down the development of a larger project into smaller, more manageable chunks.

Each iteration builds on the previous one, adding on more features and gradually increasing the complexity of the working product until there’s a customer-ready and fully-functional application or project deliverable.

Some benefits of following an iterative process:

Allows for course correction during the process: With each sprint cycle, the team gains a better understanding of what’s required and allows them to incorporate these learnings into future sprints.

Improves team motivation during the work process: With each iteration, the team produces work better suited for the final stakeholder or customer.

What are the critical roles in a Scrum team?

Although Scrum teams may adapt their roles to fit their needs, they are generally comprised of five different roles.

⁠

Source:

BMC⁠

⁠

Scrum master

The Scrum Master acts as a mentor and overall project manager for the Scrum team. They take instructions from the product owner and assign tasks to the Scrum team to deliver the right results. They help drive the cross-functional Scrum team to solve problems effectively and ensure the team follows Scrum processes, including sprint planning, review, and sprint retrospectives.

Scrum masters meet with the team regularly to review progress, coach team members, remove roadblocks the Scrum team faces, and encourage accountability. They also help to organize meetings with the product owner and keep project information collected and up-to-date.

Product owner

The product owner acts as the overall ‘CEO’ of the product and sets the direction for product development and progress. They are the bridge between the entire Scrum team and business stakeholders, taking stakeholder needs and long-term business vision into consideration and communicating these requirements to the Scrum master and Scrum team.

Product owners manage the product backlog and prioritize backlog items based on business needs.

Scrum team

The Scrum team’s key role is to perform and complete work assigned during the project sprint by the Scrum master and product owner. Individual Scrum team members should know how to self-organize and complete assigned tasks in the most efficient way possible. The Scrum Master also empowers the team to solve issues as they arise.

Scrum teams comprise various specialties, from product designers, UX specialists, quality assurance, and front-end/back-end developers.

Including the product owner and Scrum Master, the team should comprise no more than

nine people⁠

and be accountable for their output as one team.

How does the Scrum methodology work?

Each role in the Scrum team plays a critical role in each sprint. A typical sprint cycle in the Scrum methodology looks something like the image below: a cycle (the sprint) that is split into four parts.

⁠

⁠

Image source:

Atlassian Agile Coach⁠

⁠

1. Sprints

“A sprint is a short, time-boxed period when a Scrum team works to complete a set amount of work.” -
Atlassian Agile Coach⁠
⁠

Sprints are central to the Scrum methodology and Agile framework. Like Scrum itself, they break down more significant projects into smaller, more manageable chunks of work. Sprints help teams ship faster and more frequently while allowing for the flexibility to adapt to changes.

Sprints can last anywhere between 1-4 weeks, but typically last two weeks long. Each sprint consists of the following four events, which I’ll explain below:

Sprint planning

Daily Scrum

Sprint review

Sprint retrospective

⁠

Use this Coda template to plan your Scrum project ⁠

⁠

2. Sprint planning

Sprint planning marks the start of the current sprint and is conducted with the entire Scrum team to discuss what to deliver in the current sprint and how to complete it. The entire sprint planning session should take no more than two hours.

What happens during a typical sprint planning session:

Product backlog items (PBIs) should be updated. The product owner should come with lessons learned from the sprint review, feedback from business stakeholders, and a vision for the sprint.

Product owner and Developer discuss which Product Backlog Items (PBIs) to include in the upcoming sprint

Product owner sets out the overall goal of the sprint and prioritizes PBIs based on stakeholder requirements and project circumstances to achieve the given plan.

Developers discuss if these items are feasible and raise issues where necessary. They consider available time and resources and agree on deliverables for the sprint.

Ideal outcome: The team can describe the overarching goal of the sprint and how to achieve that goal. Goals should be achievable and realistic based on current capacity.

⁠

Use Coda’s Scrum sprint planning template to plan your sprint. ⁠

⁠

3. Daily Scrum (AKA, the daily standup)

The daily Scrum meeting (or daily standup) is a meeting with the entire Scrum team (including the Scrum master and product owner) where everyone gives quick status update and checks-in on the team’s progress. Standups are short meetings. They should take no more than 15 minutes and should be at a regular time that’s convenient for all.

What happens during a typical Scrum meeting:

Each person shares their successes, challenges they’re facing, and what they’re planning to work on today. The team also uses the product backlog to measure and track their progress.

Every team’s Scrum meeting might be different, depending on their needs at the time. If you’re stuck, ask your team members to answer these three questions during your daily scrum meetings:

What did I work on yesterday?

What am I planning to work on today?

Do I have any issues or challenges that are hindering progress?

Ideal outcome: Each team member is encouraged and motivated. They have a clear idea of what they’re working on and what their team members are working on. If they face any challenges, the product owner or Scrum master should be on hand to help unblock their progress.

4. Sprint review

A sprint review usually takes place at the end of the sprint. Sprint reviews give the spotlight to the Scrum team for them to describe and showcase the work they’ve completed during the project sprint. These meetings usually consist of the product owner, Scrum master, and the entire Scrum team. External stakeholders may join if needed.

What happens during a typical sprint review:

Team members show what they’ve accomplished during the sprint. This can look like informal product demos and inspecting working features created during the sprint.

Celebrate the team and everyone’s accomplishments.

Sprint reviews should be a positive team event and help to bolster the morale of the team. However, if the sprint review didn’t produce a good outcome, the Scrum master or product owner should note it. Every team has the occasional weak sprint but asks questions to assess and move towards a solution.

Is the team taking on too much work?

Is the product owner changing priorities within iterations? Am I hindering the team through scope creep?

Can the team’s working practices be improved?

Is the team struggling with existing technical debt? (For example: prioritizing speed of delivery over accurate code)

Note: The sprint review is different from the

sprint retrospective⁠

. Sprint reviews focus on the work completed during a sprint. In comparison, a sprint retrospective takes a higher-level view on the sprint and reflects on the past sprint to improve future sprints from a process or strategic level.

5. Sprint retrospective

A sprint retrospective gives a Scrum team space and time to reflect on becoming more effective as a team.

What happens during a typical retrospective:

Teams think about:

What went well during the sprint

What they wish could be improved

Ideas and suggestions to create a more efficient sprint

How to take the lessons from this sprint into future sprints

The focus is on individual team members and should be a nurturing environment for them to share feedback, celebrate work well done, and reflect on what could be improved. Finally, retrospectives allow team members the space to come up with solutions together.

Ideal outcome:

The team comes up with a list of items that worked well and what didn’t work well during a sprint.

Prioritize these items by importance and discuss common themes between items.

Discuss what can be done to improve the essential items

Create a plan of action with clear owners and due dates to move forward

Scrum artifacts

In software development, the term artifact refers to crucial information needed during the development of a product. Scrum teams use this information to put Scrum’s core principles of transparency, inspection, and adaptation into practice. It also enables the team to understand how the sprint is genuinely performing.

The team uses Scrum artifacts to:

Plan work and goals

Create the daily tasks needed to achieve these goals

Organize sprints according to priority or identify dependencies

Execute daily tasks

Review and analyze results from these tasks and readjust where needed

Although there are many potential Scrum artifacts, I’ll dig into four you’ll probably see frequently.

1. Product backlog

The product backlog functions as a comprehensive to-do list for the Scrum team for the entire project.

It lists desired new features, enhancements, bug fixes, and requirements to complete the project. Owned and maintained by the product owner between sprint cycles, the product owner should consult external sources and critical stakeholders to complete the list.

Get started with creating your product backlog with

Coda’s product backlog template here. ⁠

⁠

2. Sprint backlog

The sprint backlog contains a list of product backlog items that the Scrum team has chosen to work on during a sprint. The sprint backlog is further broken down into specific, actionable tasks for the Scrum team to complete during a sprint. Each task is given an effort estimate to complete, usually expressed as story points.

The Scrum team owns the sprint backlog. Sprint backlog items are reviewed and planned during a sprint planning meeting. If there are unfinished items after the sprint, these are added back to the product backlog and addressed during the next sprint

A good sprint backlog also includes:

Time estimates for individual tasks

What the ‘definition of done’ looks like for each task

Create your own Scrum board from one of

Coda's templates.⁠

⁠

3. Product increments

Also known as sprint goals, product increments are the usable end-product from a sprint. Items that meet the Scrum team’s definition of achieving a milestone or completing a sprint goal become product increments.

Product increments are part of the continuous feedback ethos of the Scrum methodology. Investing in new product features in small amounts helps teams receive and adapt to any feedback regularly. They also have a concrete way to measure progress using this method.

4. Burndown chart

A burndown chart easily demonstrates how much work the Scrum team has left to do and helps estimate when work will be completed. Typically, the vertical axis shows outstanding work with time (sprint number) along the horizontal axis.

Benefits of using a burndown chart in the Scrum methodology:

Keeps the team running on schedule

Compare planned work against how the team is progressing

Monitoring project scope creep

⁠

Create your sprint overview tracker, including a burndown chart using Coda’s template.⁠

And read more information about burndown charts in my doc:

What Is A Burndown Chart & How To Create One⁠

Definition of "done."

This may seem like a simple question. What does ‘done’ actually mean for the Scrum team? But defining this is critical for your Scrum methodology workflow.

Scrum teams need a way to determine if a task is complete or not. ‘Done’ can mean many different things depending on the organization. Is a project done when it’s pushed live to production? Is it done when release notes and a change log are completed?

⁠

Software engineer Danny Smith gives one way of defining done.⁠

⁠

The story must meet the acceptance criteria defined by the product owner

Everything on the to-do list for this story must be completed

Complete a code review

It must be tested

It must be immediately deployable.

Some teams employ multiple definitions of ‘done.’ They vary criteria depending on whether the item is a bug fix, feature, or technical task.

Six questions to help you decide when to use Scrum project management

All this considered, when should a project manager use the Scrum methodology for their projects? Here are several criteria to consider if you want to go ahead with Scrum.

1. Are your project requirements clearly defined?

Scrum’s flexible and iterative approach thrives on projects without precise requirements. Apply this when your customer or key stakeholder has a general idea of what they want to see but is unsure how to get there.

2. Do you anticipate rapid change during the development process?

If you think there’s a high possibility of changes despite clearly defined requirements, use the Scrum methodology. Its iterative process and regular review cycles give your Scrum team an easier time dealing with new conditions or changes during the project lifecycle.

3. Do you need to test your solution during its creation?

The Scrum working process allows rapid processing of feedback on finished work products and basing future iterations based on feedback. Employ this methodology when you anticipate interim testing of your work products during their creation.

4. Is your Scrum team experienced enough to self-manage?

Scrum’s working style thrives on independent decision-making and self-motivation. It usually works best with team members with a certain amount of initiative and seniority. Besides the Scrum master, team members are left to their own devices when deciding how to get work done.

5. Do you have people who can step up and own the role of the product owner and Scrum master for the project?

These are critical roles to make a Scrum team successful.

6. Is your organization or client familiar with the Scrum process?

Clients or stakeholders may have questions about costs or how long it takes for something to develop. These are difficult to answer as Scrum thrives on change without a defined endpoint. Scrum works best when there’s a mutual relationship of trust and accountability, and there’s a straightforward way to show the progress or performance of the Scrum team over time.

Scrum methodology FAQs

What's the difference between Scrum and Kanban?

Both Scrum and Kanban are ways to organize work for teams effectively. Scrum emphasizes the time-based nature of scheduling and doing work. Work is broken down into manageable chunks within a specific time (also known as sprints).

Kamban, on the other hand, focuses on visualizing work as it progresses through the entire project workflow. It places a hard limit on the number of items allowed to be in each stage but has no requirements on scheduling like time boxing or iterations.

Scrum needs people in critical roles like the product owner and scrum master to succeed, whereas Kanban has no such requirement. Scrum also relies on cross-functional teams, whereas all teams involved in the project, regardless of composition, use the Kanban method.

What is the difference between Scrum and waterfall?

The waterfall development model follows a traditional, linear, and sequential approach to software development. Projects are defined into clear stages, and one activity must be completed before starting another. Customers or key stakeholders are only involved towards the end of the project once work products are completed and changes are only made at the requirements stage in the waterfall model.

Given the rigid nature of the waterfall development model, it’s more suited for smaller projects with clearly defined scopes and requirements.

In comparison, the Scrum methodology involves customers and key stakeholders consistently throughout the project. The team ships completed work products and demonstrates them to the customer or stakeholder consistently, allowing for feedback or adaptive changes. Requirements and reviews are done consistently throughout the whole project. Work is divided into sprints, versus phases in the waterfall method.

Scrum is therefore more suited for larger projects with more uncertainty around scope or requirements because of this flexible nature.

Can project managers blend different methodologies?

Yes it’s possible. You could plan projects using a waterfall method with a clear work breakdown structure and execute using an Agile or Scrum method to break down work into shorter sprints and review cycles. This helps you get the best of both methodologies.

To put this into practice, identify two methodologies you wish to use for your project, evaluate which aspects you want to use for each part of your project and put this into practice. Make sure to re-evaluate your method to see if it resonates with your team and include discussions in your regular review meetings.

How do product backlogs and sprint backlogs work together?

There’s a critical difference between a product backlog and a sprint backlog. A sprint backlog is a subset of a product backlog and describes the tasks to complete a specific product backlog item.

⁠

Source:

PM World Network⁠

⁠

Let’s say you have a task to revamp the homepage of a website which requires work from design and development. This is how the product backlog and sprint backlogs could look like.

Product backlog task:

Revamp website homepage

Sprint backlog tasks:

Create a website homepage mockup

Program contact forms and integrations

Prepare website content and get approval from marketing/corporate communications

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.