Home

05 Agile Development Part 2: Scrum Framework and Real-World Application

January 2026 (6528 Words, 37 Minutes)

lecture agile scrum sprints user-stories project-management

1. Introduction: From Practices to Process

In Part 1, we explored the philosophical foundation of Agile development:

We also applied these concepts to our Road Profile Viewer project, writing user stories with acceptance criteria and learning how to track them using GitHub Issues.

But practices alone don’t make a project succeed. You also need a framework for organizing work: Who decides what to build next? How do you know when something is “done”? How do you improve over time?

In this lecture, we examine Scrum — the most widely adopted Agile framework. We’ll see how Scrum’s roles, events, and artifacts provide structure while maintaining Agile flexibility. Then we’ll apply Scrum to a concrete sprint for the Road Profile Viewer, and conclude with real-world evidence that Agile works even in the most demanding environments.

2. Learning Objectives

By the end of this lecture, you will be able to:

  1. Describe the three Scrum roles and their responsibilities (Product Owner, Development Team, Scrum Master)
  2. Explain the five Scrum events and their purpose (Sprint, Planning, Daily Scrum, Review, Retrospective)
  3. Distinguish the three Scrum artifacts (Product Backlog, Sprint Backlog, Product Increment)
  4. Plan a realistic sprint for a small team project, including goal, backlog, and timeline
  5. Recognize real-world Agile adoption including in highly regulated environments like the US Military
  6. Connect Scrum practices to testing — understanding how sprints integrate with TDD and CI

3. Scrum Framework

While XP provides technical practices, Scrum provides a management framework for organizing Agile work. Created by Ken Schwaber and Jeff Sutherland in the early 1990s (and first publicly presented at the OOPSLA conference in 1995), Scrum has become the most widely adopted Agile framework worldwide.

3.1 What Is Scrum?

The official Scrum Guide defines Scrum as:

“A lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

Notice what Scrum is not: it’s not a methodology, not a process, not a set of rules to follow blindly. It’s a framework — a minimal structure that teams adapt to their specific context.

In a nutshell, Scrum works like this:

  1. A Product Owner orders the work for a complex problem into a Product Backlog
  2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint
  3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint
  4. Repeat

That’s it. Everything else in Scrum exists to make these four steps work effectively.

3.2 Scrum Theory: Empiricism and Lean Thinking

Scrum is founded on two intellectual traditions:

Empiricism — Knowledge comes from experience and making decisions based on what is observed, not what is predicted. This connects directly to Herbert Simon’s bounded rationality from Part 1: since we can’t fully predict complex systems, we must learn by doing.

Lean Thinking — Reduce waste and focus on the essentials. Every element in Scrum exists for a reason; if something doesn’t contribute value, eliminate it.

These foundations manifest in Scrum’s three pillars:

graph LR
    subgraph Pillars["Three Pillars of Scrum"]
        T[Transparency] --> I[Inspection]
        I --> A[Adaptation]
    end
Pillar Meaning In Practice
Transparency The work and process must be visible to those doing the work and receiving the work Sprint boards, daily standups, public backlogs
Inspection Frequently examine progress and artifacts to detect problems early Sprint reviews, retrospectives, daily check-ins
Adaptation When inspection reveals issues, adjust the process or product immediately Backlog reprioritization, process improvements, scope negotiation

The key insight: Inspection without transparency is misleading. Adaptation without inspection is pointless. All three pillars must work together.

3.3 The Five Scrum Values

The Scrum Guide emphasizes that successful Scrum depends on people “becoming more proficient in living five values”:

Commitment, Focus, Openness, Respect, and Courage

These aren’t just nice words on a poster. Each value serves a practical purpose:

For your Road Profile Viewer project: When a teammate is struggling with a feature, respect means trusting they can solve it while openness means they’ll ask for help if needed. Courage means admitting “I don’t understand this requirement” rather than building the wrong thing.

3.4 The Structure: 3-5-3

Scrum defines a minimal but complete structure:

Each artifact also has a commitment that provides focus:

Let’s examine each component in detail.

3.5 The Three Accountabilities

Role Responsibilities NOT Responsible For
Product Owner
  • Defines and prioritizes the Product Backlog
  • Represents the customer/stakeholders
  • Accepts or rejects completed work
  • Communicates the product vision
  • Technical implementation decisions
  • Assigning tasks to individuals
  • Managing the development team
Development Team
  • Self-organizing (decides how to do the work)
  • Cross-functional (has all skills needed)
  • Delivers a potentially releasable increment each sprint
  • Typically 3-9 people
  • Prioritizing the backlog
  • Stakeholder communication (that's PO's job)
  • Sub-teams or hierarchies
Scrum Master
  • Facilitates Scrum events
  • Removes impediments blocking the team
  • Coaches the team on Scrum practices
  • Protects the team from outside interference
  • Managing the team (not a manager role)
  • Making technical decisions
  • Assigning work

3.6 The Five Events

Scrum defines five time-boxed events (ceremonies):

graph LR
    subgraph Sprint["Sprint (1-4 weeks)"]
        SP[Sprint Planning] --> DS[Daily Scrum]
        DS --> DS
        DS --> SR[Sprint Review]
        SR --> RT[Retrospective]
    end
    RT --> SP2[Next Sprint Planning]
Event Duration Purpose Output
Sprint 1-4 weeks (fixed) Container for all other events; time to produce an increment Potentially releasable product increment
Sprint Planning 2-4 hours Select work for the sprint; define sprint goal Sprint Backlog and Sprint Goal
Daily Scrum 15 minutes Synchronize team; identify blockers; plan next 24 hours Updated plan for the day
Sprint Review 1-2 hours Demonstrate completed work to stakeholders; gather feedback Feedback for Product Backlog updates
Sprint Retrospective 1-2 hours Reflect on process; identify improvements Action items for next sprint

3.7 The Three Artifacts

Artifact Description Owned By Example
Product Backlog Prioritized list of everything that might be needed in the product Product Owner All user stories, bugs, technical debt items
Sprint Backlog Items selected from Product Backlog for current sprint + plan to deliver them Development Team Stories selected for Sprint 3 + breakdown into tasks
Product Increment Sum of all completed Product Backlog items + all previous increments Development Team Working software with new features from current sprint

3.8 The Sprint Cycle

The following diagram shows how all Scrum elements work together in a continuous cycle. Notice how feedback flows back into planning, creating a self-improving system:

Sprint 1-4 weeks
📋 Product Backlog
💬 Stakeholder Feedback
📝 Sprint Planning
📑 Sprint Backlog
🔄 Daily Scrum
💻 Development Work
📦 Product Increment
🔍 Sprint Review
🪞 Retrospective
📈 Process Improve
Planning Phase
Execution Phase
Review Phase
Improvement Phase

Reading the cycle clockwise from the top:

  1. Planning Phase (blue): Sprint Planning selects items from the Product Backlog and creates the Sprint Backlog
  2. Execution Phase (green): Daily Scrums synchronize the team as they develop features
  3. Review Phase (purple): Completed work becomes a Product Increment, demonstrated in Sprint Review
  4. Improvement Phase (amber): Retrospective identifies process improvements that feed into the next Sprint

The cycle repeats continuously, with stakeholder feedback flowing back into the Product Backlog for future prioritization.

3.9 Velocity: How Teams Learn to Estimate

Velocity is a measure of how much work a team can complete in a single sprint. It’s typically expressed in story points — an abstract measure of effort rather than hours.

How velocity works:

  1. First sprint: The team estimates stories and selects what seems achievable
  2. After sprint: Count the points of completed stories (not started, not “almost done” — done)
  3. Next sprint: Use that number as a guide for how much to select
  4. Over time: Velocity stabilizes, making planning more predictable

Example for Road Profile Viewer:

Sprint Stories Attempted Stories Completed Velocity
1 15 points 10 points 10
2 12 points 11 points 11
3 13 points 12 points 12
4 12 points 12 points 12

After 4 sprints, the team knows they can reliably complete ~12 points per sprint. This makes planning realistic.

Important: Velocity is a planning tool, not a performance metric. Comparing velocities between teams is meaningless — story point scales differ. Using velocity to pressure teams to “do more” destroys its value as an honest planning tool.

3.10 The Inviolable Sprint: Why Deadlines Are Fixed

A critical Scrum principle that surprises many newcomers:

Sprints are NEVER extended. If work isn’t done, it returns to the Product Backlog.

This seems harsh, but it serves essential purposes:

Why fixed sprints matter:

  1. Forces realistic planning — Teams learn what they can actually accomplish
  2. Creates predictable rhythm — Stakeholders know when to expect demos
  3. Prevents scope creep — No “just one more day” that becomes a week
  4. Exposes estimation problems early — Rather than hiding them with extensions

What happens when work isn’t completed:

graph LR
    US[Unfinished Story] --> PB[Returns to Product Backlog]
    PB --> PO[Product Owner Re-prioritizes]
    PO --> NS[May be selected for next sprint]
    PO --> L[Or may be deprioritized]

The team’s response should be:

NOT: Work overtime to finish, extend the sprint, or mark incomplete work as “done.”

3.11 The Scrum Board: Making Work Visible

The Scrum Board (or Sprint Board) is a visual representation of work in the current sprint. Originally a physical whiteboard with sticky notes, it’s now often digital.

Typical columns:

To Do 3
ROAD-4 5 pts
Compare two profiles side-by-side
feature ui
ROAD-5 3 pts
Export profile to PDF
feature
ROAD-4.1
Design comparison layout
MK
Max K.
In Progress 2
ROAD-3 5 pts
Upload profiles via JSON
upload
LS
Lisa S.
ROAD-3.2
Add JSON validation
LS
Lisa S.
In Review 2
ROAD-2 3 pts
Interactive chart with zoom
ui
TM
Tom M.
ROAD-2.3
Add touch gestures for mobile
TM
Tom M.
Done 3
ROAD-1 2 pts
View stored road profiles
database
ROAD-1.1
Create database schema
ROAD-1.2
Build profile list API

Benefits of visual boards:

Physical vs. Digital boards:

Physical Board Digital Board (Jira, GitHub Projects)
Highly visible in shared office space Accessible to distributed teams
Tactile — satisfying to move cards Automated metrics and burndown charts
No learning curve Integration with CI/CD and version control
Requires co-location Works across time zones

For your Road Profile Viewer project, GitHub Projects provides an excellent free digital board that integrates directly with your Issues and Pull Requests.

3.12 Why Scrum Works: Empirical Evidence

After two decades of Scrum adoption, what do teams actually report? Studies and case studies consistently identify these benefits:

1. Manageable chunks

“The product is broken down into a set of manageable and understandable chunks that stakeholders can relate to.” — Sommerville (2015)

Rather than a monolithic “the software” being delivered after months of invisible work, stakeholders see tangible progress every sprint.

2. Unstable requirements don’t block progress

In traditional waterfall, changing requirements meant stopping to re-plan. In Scrum, change is simply reprioritization of the backlog — development continues without interruption.

3. Team visibility and morale

“The whole team has visibility of everything, and consequently team communication and morale are improved.”

No one is surprised by “that feature someone else was working on.” The Daily Scrum and shared board keep everyone informed.

4. Customer trust

“Customers see on-time delivery of increments and gain feedback on how the product works. They are not faced with last-minute surprises.”

Each sprint delivers working software. Problems are discovered early, not at final delivery.

5. Positive culture

“Trust between customers and developers is established, and a positive culture is created in which everyone expects the project to succeed.”

3.13 Distributed Scrum: Working Across Locations

Scrum was designed for co-located teams who could meet face-to-face daily. But modern software development often involves distributed teams across cities, countries, or continents.

Adaptations for distributed Scrum:

Scrum Element Co-located Approach Distributed Adaptation
Daily Scrum Stand-up meeting at team whiteboard Video call or async Slack updates
Sprint Board Physical whiteboard with sticky notes GitHub Projects, Jira, or Linear
Pair Programming Shared keyboard/monitor VS Code Live Share, screen sharing
Sprint Planning Meeting room with Product Owner Video conference with shared screen
Informal communication Hallway conversations Slack channels, video calls

Key requirements for distributed Scrum success:

  1. Scrum Master with the team — The SM should ideally be in the same location as most developers to understand daily challenges
  2. Product Owner visits — The PO should periodically visit the development team to build relationships and trust
  3. Overlap hours — Teams in different time zones need some shared working hours for synchronous communication
  4. Continuous Integration — Automated builds and tests so all team members see the current system state
  5. Common development environment — Docker, devcontainers, or standardized tooling so “works on my machine” isn’t an issue

3.14 Scaling Scrum: Multiple Teams

What happens when a project is too large for a single Scrum team (7±2 people)?

Multi-team Scrum introduces coordination challenges:

Key scaling patterns:

1. Role Replication

Each team has its own Product Owner and Scrum Master. For large products, there may be a Chief Product Owner who coordinates across teams.

2. Product Architects

Each team nominates a technical representative. These architects meet regularly to design and evolve the overall system architecture, ensuring teams’ work integrates smoothly.

3. Release Alignment

All teams align their sprint dates so releases can be coordinated. At the end of each sprint, a demonstrable integrated system should exist.

4. Scrum of Scrums

A daily meeting where representatives from each team synchronize:

graph TD
    T1[Team 1 Daily Scrum] --> SoS[Scrum of Scrums]
    T2[Team 2 Daily Scrum] --> SoS
    T3[Team 3 Daily Scrum] --> SoS
    SoS --> COORD[Cross-team coordination]

Scaling frameworks:

For large enterprises, formal scaling frameworks exist:

For your Road Profile Viewer project with 3 people, you won’t need these — but in industry, you’ll likely encounter them.

4. Example Sprint for Road Profile Viewer

Let’s see how a team might execute a sprint for the Road Profile Viewer project.

4.1 Sprint Goal

Sprint Goal: Enable users to select and upload road profiles with database persistence.

4.2 Sprint Backlog

Story Tasks Status
Database Setup
  • Design SQLite schema
  • Implement database module
  • Create seed script
  • Write unit tests
 Done
Data Validation
  • Define Pydantic model
  • Add validation rules
  • Write unit tests
 Done
Profile Selection
  • Add dropdown component
  • Wire to database queries
  • Update chart on selection
  • Write integration tests
 In Progress
Profile Upload
  • Create /upload route
  • Build upload form
  • Implement preview graph
  • Connect to validation & database
  • Write integration tests
 To Do

4.3 Two-Week Sprint Timeline

Week 1:

Week 2:

4.4 Sprint Board Visualization

To Do
3 items
→
In Progress
2 items
→
In Review
2 items
→
Done
3 items
↩ Rework: Review → In Progress

Modern tools like Jira, Linear, or GitHub Projects provide digital sprint boards. For the Road Profile Viewer project, GitHub Projects would integrate well with your existing repository.

5. Real-World Evidence: US Military Agile Adoption

One common objection to Agile is: “That might work for web apps, but not for serious projects.” The US Military’s recent pivot to Agile directly contradicts this argument.

5.1 Why Military Software Is the Ultimate Stress Test

Before examining the military’s Agile adoption, let’s understand why this is significant. Military software systems represent perhaps the most challenging environment for any development methodology. Sommerville (2015) identifies six factors that make large systems difficult — military software has all of them:

Challenge Factor Description Military Example
System of Systems Multiple separate systems that must communicate and integrate Aircraft, ground vehicles, command centers, satellites — all must share data
Brownfield Development New software must integrate with existing legacy systems Decades-old radar systems, communication protocols, database formats
Regulatory Constraints External rules governing development, testing, and documentation Security clearances, safety certifications, acquisition regulations
Prolonged Procurement Long timelines from initial specification to deployment Major weapon systems can take 10+ years from concept to fielding
Diverse Stakeholders Many different users and decision-makers with competing priorities Soldiers, commanders, contractors, Congress, allied nations
Life-Critical Systems Software failures can result in loss of life Weapon targeting, vehicle control, medical systems

The traditional argument: These challenges require extensive upfront planning, detailed specifications, and rigorous phase-gate processes. Agile’s flexibility would introduce unacceptable risk.

The emerging reality: These challenges actually make Agile more valuable, not less. When requirements inevitably change (as they do in evolving threat environments), the ability to adapt quickly becomes a strategic advantage.

5.2 US Army Policy (March 2024)

In March 2024, the US Army announced a sweeping new policy mandating Agile software development practices across the entire organization.

Secretary of the Army Christine Wormuth:

“We’re learning from current conflicts — including in Ukraine — that the Army’s success on future battlefields will depend on our ability to rapidly update software and disseminate it to the operational force.”

The policy institutionalizes five major changes:

Traditional Army Approach New Agile Approach
Detailed, prescriptive requirements documents Concise, high-level needs with continuous soldier involvement
Rigid acquisition strategies Software Acquisition Pathway with modular contracting
Duplicative testing phases Streamlined, continuous testing integrated with development
Development ends at deployment Continuous improvement across the entire lifecycle
Scattered expertise Digital Capabilities Contracting Center of Excellence

5.3 Platform One DevSecOps

The US Air Force’s Platform One provides a cloud-native DevSecOps platform for military software. It represents a fundamental shift in how the military approaches software infrastructure.

What Platform One provides:

Why this is revolutionary:

Traditional military software procurement might look like:

  1. Write detailed requirements (6-12 months)
  2. Select contractor (6-12 months)
  3. Development (2-5 years)
  4. Security certification (6-18 months)
  5. Deployment

With Platform One and Agile practices:

  1. Continuous collaboration with users
  2. Sprint-based development with frequent releases
  3. Automated security testing on every commit
  4. Continuous deployment to pre-certified infrastructure

The result: Software that would have taken years to deploy now reaches soldiers in months or weeks.

5.4 The Ukraine Factor: Agile Under Fire

The 2022 Russian invasion of Ukraine has provided an unprecedented real-world test of software agility in warfare. Ukrainian forces have demonstrated:

Secretary Wormuth’s quote directly references these lessons:

“We’re learning from current conflicts — including in Ukraine — that the Army’s success on future battlefields will depend on our ability to rapidly update software and disseminate it to the operational force.”

This isn’t abstract theory — it’s the observed reality of modern warfare, where software updates can be as important as ammunition resupply.

5.5 Implications for Software Engineering

If the US Military — one of the most regulated, life-critical, and security-conscious organizations on Earth — is adopting Agile practices, what does this mean for the software industry?

1. The “Agile doesn’t scale” myth is dead

Military systems are among the largest, most complex software projects on Earth. If Agile works there, the “it only works for small web apps” argument no longer holds.

2. Security and Agile are compatible

DevSecOps proves that rigorous security doesn’t require waterfall. Automated testing, continuous compliance monitoring, and security-by-design can coexist with rapid iteration.

3. Regulated industries will follow

Healthcare, finance, aerospace, automotive — these industries face similar pressures (though less extreme). The military’s successful adoption creates a template for other regulated domains.

4. The real question has changed

It’s no longer “Should we use Agile?” but “How do we adapt Agile to our specific constraints while maintaining its core benefits?”

The lesson for your career: Agile isn’t just for startups building mobile apps. It’s for any organization that needs to:

When you interview at traditional enterprises and they say “we do waterfall because our domain requires it,” you can now point to the US Military as a counterexample.

6. Summary

Concept Key Point Connection to Testing
Scrum Roles Product Owner (what), Development Team (how), Scrum Master (process) Team decides testing strategy; SM removes testing impediments
Scrum Events Sprint, Planning, Daily, Review, Retrospective Review demos tested features; Retro improves test practices
Scrum Artifacts Product Backlog, Sprint Backlog, Increment Increment must be "potentially releasable" — requires tested code
Sprint Planning Select stories, define goal, break into tasks Tasks include "write tests" for each feature
Military Adoption Even highly regulated environments (US Army) are mandating Agile practices DevSecOps integrates security testing into CI/CD pipeline

6.1 Key Takeaways

  1. Scrum provides structure without sacrificing Agile flexibility — roles, events, and artifacts create predictability.
  2. Sprints create rhythm — time-boxed iterations with clear goals and accountability.
  3. The Product Owner owns “what”, the Development Team owns “how” — clear separation of concerns.
  4. Retrospectives drive improvement — the team continuously refines its process.
  5. Real-world evidence validates Agile — even the US Military is adopting these practices for mission-critical systems.

7. Reflection Questions

  1. Role mapping: In your Road Profile Viewer team, who would serve as Product Owner? Scrum Master? How would you handle these roles with only 3 team members?

  2. Sprint sizing: Your Road Profile Viewer team has 3 members and 3 weeks. Design a realistic sprint schedule. How long would your sprints be? Which events would you keep or modify?

  3. Backlog prioritization: Given the 5 user stories from Part 1, in what order would you tackle them? What dependencies affect your ordering?

  4. Daily Scrum value: Some teams find the Daily Scrum repetitive. What value does it provide? When might a team skip it?

  5. Military case study: What surprised you about the US Army adopting Agile? How does this change your perception of Agile’s applicability to different domains?

  6. Process adaptation: The Scrum Guide says “Scrum is a framework, not a methodology.” What does this mean for how you might adapt Scrum for a 3-person student team?

8. Further Reading

8.1 Books

8.2 Articles and Resources

8.3 Tools

9. What’s Next

With Agile foundations (Part 1) and Scrum framework (Part 2) complete, you now have the tools to:

In your Road Profile Viewer project, apply these concepts:

  1. Create a Product Backlog as GitHub Issues
  2. Plan a sprint with a clear goal
  3. Use Daily Standups (even async on Slack/Discord) to stay synchronized
  4. Hold a Sprint Review to demo your progress
  5. Run a Retrospective to identify improvements

The best way to learn Agile is to practice it.

Coming Up: Software Architecture

Agile tells us how to organize work. But what about organizing the system itself?

In Lecture 10: Software Architecture, we’ll explore:

You’ve learned to deliver fast. Now learn to build systems that can grow.

© 2026 Dominik Mueller   •  Powered by Soopr   •  Theme  Moonwalk