Introduction

Agile Scrum gets mentioned in almost every conversation about modern software development, and almost as often, misunderstood. Teams call daily meetings "stand-ups" and two-week cycles "sprints" without necessarily following the roles, events, and artefacts that actually make Scrum work.

That gap matters. A team running "Scrum-ish" without the actual structure underneath it tends to get the downsides, meetings, ceremony, overhead, without the upside: faster feedback loops, clearer priorities, and a genuine reduction in wasted work.

This guide covers what Agile Scrum actually is, the pillars and values it's built on, how it compares to Kanban, where it came from, and how to tell whether a team running Scrum is actually getting the benefits it promises.

Key takeaways

• Agile is a philosophy; Scrum is a specific framework for putting that philosophy into practice through fixed-length sprints
• Scrum is built on three pillars, transparency, inspection, and adaptation, and five values: commitment, courage, focus, openness, and respect
• A Scrum team has three accountabilities: Product Owner, Scrum Master and Developers
• Scrum suits product and feature development where predictability and structure matter; Kanban suits continuous flow work like support or operations
• Scrum was developed in the early 1990s by Jeff Sutherland and Ken Schwaber, building on ideas first described in a 1986 Harvard Business Review article
• Sprint velocity and burndown charts are the standard ways to measure whether a Scrum team's process is actually improving over time
• Cross-functional Scrum teams typically need more than coders: design, business analysis and QA skills all belong inside the team, not outside it

Table of contents

• What is Agile Scrum methodology?
• The Scrum methodology
• What are the three pillars and five values of Scrum?
• Where did Scrum come from?
• The Scrum framework
• How does Scrum compare to Kanban?
• Scrum process in action
• How do you measure whether Scrum is actually working?
• Applying Scrum in Agile environments
• How does Dapth apply Scrum across different types of projects?
• The takeaway
• Frequently asked questions

What is Agile Scrum Methodology?

Defining Agile Scrum Methodology

Agile Scrum is a methodology combining the best of both worlds - the agile philosophy and Scrum frameworks. It allows teams to develop projects in small increments using sprints, which are sizeable chunks of work. This approach offers several benefits - including faster product development and more efficient project management by breaking it down into smaller stages.

The greatest benefit of the Scrum method in Agile lies in its flexibility. Stakeholders can provide feedback after each sprint, meaning it allows for frequent adjustments, unlike traditional project management systems that don't provide stakeholders with regular feedback. This way, stakeholders are involved in each step.

Agile Scrum methodology is defined by a dynamic, iterative framework focused on collaboration, adaptability, and incremental progress. This methodology is essential in the ever-evolving landscape of project development, and Agile Scrum has had a transformative force on project management.

What are the three pillars and five values of Scrum?

Scrum's structure (roles, events and artefacts) rests on a smaller set of ideas that explain why the framework works the way it does.

Three pillars support Scrum's empirical approach to work:

• Transparency: the work and the process must be visible to everyone responsible for the outcome, not hidden inside one person's head or one team's private notes.
• Inspection: progress is checked frequently enough to catch problems early, without slowing the work down to check it constantly.
• Adaptation: when inspection reveals something isn't working, the team adjusts, rather than sticking to a plan that's clearly gone stale.

Five values guide how a Scrum team behaves day to day: commitment to the team's goals, courage to raise hard problems, focus on the current sprint rather than everything at once, openness about progress and blockers, and respect for every team member's contribution.

None of these are abstract ideals. A team missing openness hides slipping deadlines until it's too late to fix them. A team missing focus never finishes what it starts. The pillars and values aren't a poster on the wall, they're the reason the roles, events, and artefacts covered elsewhere in this guide actually produce better outcomes than working without them.

Where did Scrum come from?

Scrum's structure didn't appear fully formed. The underlying idea traces back to a 1986 Harvard Business Review article, The New New Product Development Game, that compared high-performing, cross-functional teams to a rugby scrum, a tight, coordinated unit moving the ball forward together rather than passing work between separate specialists.

Jeff Sutherland and Ken Schwaber formalised that idea into the Scrum framework in the early 1990s, developing it specifically to manage the complexity of software projects that traditional, sequential project management struggled to handle. Their work became the Scrum Guide, still the definitive reference for the framework today.

Scrum has since moved well beyond its software origins. It's now used across marketing, operations, and product teams of every kind, and is consistently reported as the most widely used Agile framework.

The Scrum Framework

The Scrum framework is a widely used Agile methodology employed in software development to manage and complete complex projects effectively. It is based on a set of guidelines and principles that help teams work collaboratively and deliver high-quality products efficiently. To understand the Scrum framework - it's essential to understand its key components: roles, events, and artefacts.

During Scrum project management, roles within the Scrum framework are divided into three key positions:

• Scrum Master
• Product Owner
• Developers

The Scrum Master is responsible for ensuring that the Scrum framework is being implemented correctly and the process is facilitated smoothly. The Product Owner is responsible for defining and prioritising the product backlog, which includes the features, enhancements, and bug fixes that are being prioritised for the development team. The Developers are the cross-functional people who build each increment. (The 2020 Scrum Guide replaced 'Development Team' with 'Developers' so the whole Scrum Team is seen as one unit.)

Scrum methodology employs several events to help teams collaborate and ensure the project is on track. There are five events: the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective.

The Sprint is a fixed period of one month or less in which the Developers work on the items from the product backlog. Daily Scrum is a daily stand-up meeting for the Developers to discuss the progress made so far, any roadblocks, and the plan for the day. The Sprint Review is an evaluation of the increment that has been achieved during the Sprint, and the Product Owner adapts the product backlog accordingly. The Sprint Retrospective is a reflective session to discuss the past Sprint and plan for improvements. Scrum has three artefacts:

• Product Backlog
• Sprint Backlog
• Increment

The Product Backlog is a list of prioritised items that are to be developed. The Sprint Backlog is a subset of the Product Backlog that is selected for a specific Sprint. The Increment is the sum of all the completed Product Backlog items within a Sprint. Many teams also use a burndown chart, which shows work completed and remaining over time. It is a common practice, not an official Scrum artefact.

The Scrum framework is an iterative and incremental Agile methodology focused on delivering customer value. It emphasises teamwork, communication, and collaboration, and the key components include roles, events, and artefacts. By following the Scrum framework, teams can deliver high-quality products efficiently and effectively.

How does Scrum compare to Kanban?

Scrum isn't the only Agile framework, and it isn't always the right one. Kanban, its most common alternative, takes a fundamentally different approach to structuring work.

Scrum's fixed sprints and defined roles give teams predictability, useful when a business needs to plan releases and forecast delivery dates. Kanban's continuous flow suits work that arrives unpredictably and needs to be picked up quickly, support tickets, ad hoc requests, or operational tasks that don't fit neatly into a two-week box.

Some teams blend the two, keeping Scrum's backlog and planning discipline while adopting Kanban's flexibility in how work moves through execution, often called Scrumban. The right choice depends on whether the work itself is predictable enough to plan two weeks ahead, not on which framework is more fashionable.

Scrum process in action

The Scrum process involves several phases, each with its own unique purpose. To walk through the Scrum process, let's start with sprint planning and go through to the sprint review and retrospective.

The first phase is sprint planning, where the Scrum team collaboratively plans the work for the upcoming Sprint. During this phase, the team defines sprint goals and selects the backlog items that will be tackled during the iteration. It is a crucial step for ensuring that everyone is on the same page and working towards a common goal.

Next, are the daily stand-ups, key to the Scrum process. During these meetings, team members provide updates on their progress, share any impediments and coordinate efforts to ensure that everyone is aligned. These meetings are quick and focused, usually only lasting around 15 minutes, and promote transparency and open communication.

Scrum ceremonies are another important aspect of the Scrum process. These include sprint planning, daily stand-ups, sprint reviews, and 'metro retros' (a fancy way of saying retrospective). These ceremonies are collaborative and transparent and help promote team efficiency by encouraging open communication, shared understanding, and continuous improvement. During the sprint review, the Scrum team presents the completed work to stakeholders, gathering feedback and ensuring that the product or service aligns with stakeholder expectations. This iterative process is client-focused and promotes collaboration. Finally, in the sprint retrospective, the team reflects on the overall sprint, identifying areas of improvement and devising strategies to enhance future performance. This is an important step in the Scrum process as it helps the team to continuously improve its processes and work towards achieving its goals. The collaborative and transparent nature of Scrum ceremonies in fostering team efficiency.

A self-organised Scrum team comprises 3 to 9 individuals with business, design, analytical and development skills to execute work, solve problems and produce products. Members of the Scrum team are responsible for meeting each sprint’s goals and self-administering tasks.