Scrum - Agile Framework Simply Explained

Scrum is the world's most widely used agile framework for developing complex products. Developed in the early 1990s by Ken Schwaber and Jeff Sutherland, Scrum enables teams to incrementally deliver value in iterative cycles (Sprints) while continuously learning and adapting.

The name "Scrum" comes from rugby and describes a team's collective advance toward a goal. This metaphor illustrates the core of Scrum: a self-organized team works together toward a common goal, continuously adapts to change, and regularly delivers working results.

The 3 Scrum Roles

Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the development team. They:

• Manage and prioritize the Product Backlog
• Define and communicate the product vision
• Are the interface to stakeholders and customers
• Make decisions about features and priorities
• Accept or reject work results

Important: The Product Owner is a single person, not a committee. This clear accountability is crucial for fast decisions.

Scrum Master

The Scrum Master is the Servant Leader of the team and responsible for adherence to and improvement of the Scrum process:

• Protects the team from interruptions and distractions
• Removes impediments
• Facilitates Scrum events
• Coaches the team in agile practices
• Promotes continuous improvement
• Helps the organization understand Scrum

The Scrum Master is not a project manager or team lead in the traditional sense - they serve the team rather than leading it.

Development Team (Developers)

The development team consists of professionals who create a potentially releasable product increment at the end of each Sprint:

• Self-organized: The team decides for itself how to accomplish the work
• Cross-functional: All necessary skills are within the team
• No hierarchies or titles within the team
• Optimal size: 3-9 people (excluding Product Owner and Scrum Master)
• Shared responsibility for all work results

The 5 Scrum Events

1. Sprint

The Sprint is the heart of Scrum - a time period of maximum one month (typically 2 weeks), in which a usable, potentially releasable product increment is created.

• Fixed length: Sprints always have the same duration
• Unchanging goal: The Sprint Goal is not changed during the Sprint
• Protected framework: No changes that endanger the Sprint Goal
• Quality remains constant: The Definition of Done is not reduced

2. Sprint Planning

In Sprint Planning, the entire Scrum team plans the work for the upcoming Sprint:

• What: Which items from the Product Backlog will be implemented in the Sprint?
• Why: What is the Sprint Goal?
• How: How will the work be done?
• Duration: Maximum 8 hours for a one-month Sprint

The result is the Sprint Backlog with a clear Sprint Goal.

3. Daily Scrum (Daily Standup)

A daily 15-minute event for the development team to synchronize:

• What did I do yesterday to achieve the Sprint Goal?
• What will I do today to achieve the Sprint Goal?
• Are there any obstacles blocking me or the team?

The Daily Scrum is not a status report to the Scrum Master or Product Owner, but a planning event of the team.

4. Sprint Review

At the end of the Sprint, the team presents the finished increment to the stakeholders:

• Demonstration of completed work
• Gathering feedback from stakeholders
• Adaptation of the Product Backlog based on feedback
• Discussion about next steps
• Duration: Maximum 4 hours for a one-month Sprint

It is an informal meeting, not a formal acceptance or PowerPoint presentation.

5. Sprint Retrospective

The team reflects on the past Sprint and identifies opportunities for improvement:

• What went well? (Keep)
• What did not go well? (Drop/Improve)
• What concrete measures will be implemented in the next Sprint?
• Duration: Maximum 3 hours for a one-month Sprint

The Retrospective is crucial for continuous improvement (Kaizen) and should never be skipped.

The 3 Scrum Artifacts

Product Backlog

A prioritized list of all known requirements for the product:

• Single source of all requirements
• Continuously developed and refined (Backlog Refinement)
• Higher priority items are more detailed
• The Product Owner is responsible for content, availability, and prioritization

Sprint Backlog

The set of Product Backlog items selected for the Sprint plus a plan for implementing them:

• Belongs to the development team
• Contains the Sprint Goal
• Updated during the Sprint as needed
• Typically visualized on a task board

Increment

The sum of all completed Product Backlog items at the end of a Sprint:

• Must comply with the Definition of Done
• Must be usable and potentially releasable
• Supplements all previous increments
• Can, but does not have to, be released at Sprint end

Definition of Done (DoD)

The Definition of Done is a shared understanding of when work is considered "done":

• Code is written and reviewed
• Unit tests are written and passed
• Integration tests are passed
• Documentation is updated
• Code is merged into the main branch
• Feature is tested on staging environment

A clear DoD ensures transparency and prevents half-finished work from being declared "done".

Scrum vs. Kanban

Aspect	Scrum	Kanban
Rhythm	Fixed Sprints (1-4 weeks)	Continuous flow
Roles	Product Owner, Scrum Master, Developers	No predefined roles
Changes	Only between Sprints	Possible at any time
Planning	Sprint Planning at Sprint start	Just-in-Time, continuous
Control	Velocity, Burndown Charts	WIP limits, Lead Time, Cycle Time
Ideal for	Product development, clear releases	Support, maintenance, continuous work

Many teams combine both approaches into "Scrumban" - they use Sprints for planning and retrospectives, but a Kanban board for visualization and WIP limits.

Common Mistakes with Scrum

• Scrum-But: "We do Scrum, but without retrospectives" - partial implementations undermine the benefit
• Mini-Waterfall: Analysis, development, testing as phases within a Sprint instead of true cross-functional work
• Missing stakeholder involvement: Sprint Reviews without real feedback
• Product Owner as proxy: PO has no real decision-making authority
• No finished increment: Nothing is truly "done" at Sprint end
• Daily as status report: Developers report to the Scrum Master instead of synchronizing with each other

Scrum at Elasticbrains

At Elasticbrains we use Scrum as a proven framework for our development projects:

• 2-week Sprints: Short cycles for rapid feedback and high flexibility
• Cross-functional teams: Developers, designers, and QA work as a unified team
• Transparent communication: Regular Sprint Reviews with customers for early feedback
• Continuous improvement: Retrospectives lead to measurable process improvements
• Combination with Kanban: We use Kanban boards for visual work management
• DevOps integration: CI/CD enables releases at any time during the Sprint

Our experienced Scrum Masters and Product Owners also help with the introduction of Scrum in customer organizations.

Scrum Certifications

The most well-known certifications for Scrum practitioners:

• Scrum.org: Professional Scrum Master (PSM I, II, III), Professional Scrum Product Owner (PSPO)
• Scrum Alliance: Certified ScrumMaster (CSM), Certified Scrum Product Owner (CSPO)
• SAFe: SAFe Scrum Master (SSM) for scaled environments

Further Resources

• Scrum Guide: The official document by Schwaber and Sutherland (free at scrumguides.org)
• Books: "Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland
• Tools: Jira, Azure DevOps, Trello, Monday.com for Scrum boards