Week 1 · Day 3

Agile + DevOps

Scrum sprints, Kanban boards, and the critical bridge to continuous delivery. Understand how the planning frameworks of Agile directly enable — or block — your DevOps pipeline.

⏱ Duration 60 min

📖 Theory 30 min

🔧 Lab 25 min

❓ Quiz 5 min

Session Overview

What we cover today

01

Agile vs DevOps — Not the Same

Clear up the most common confusion: Agile is a development process; DevOps extends into delivery and operations.

02

Scrum for DevOps Teams

Ceremonies, sprint cycles, and how infra + deployment tasks belong in every sprint backlog.

03

Kanban for Ops Work

WIP limits, cycle time, and why Kanban suits operational and on-call work better than sprints.

04

DORA Metrics in Sprints

How to embed DORA tracking into retros so the team continuously improves delivery performance.

05

"Done" Redefined

In DevOps, a story is done only when it is deployed, monitored, and healthy in production.

06

🔧 Lab — GitHub Project Board

Build a Kanban board in GitHub Projects for your course labs with columns, cards, and WIP limits.

Part 1 of 5

Agile vs DevOps — different, but inseparable

Agile

Iterative development

Sprint planning & backlog

Daily standups

Sprint reviews & retros

User stories & estimation

Cross-functional teams

SHARED

Collaboration

Fast feedback

Continuous
improvement

Automation

DevOps

CI/CD pipelines

Infrastructure as Code

Automated testing

Monitoring & alerting

Release management

On-call & SRE practices

Simple Distinction

Agile answers: "How do we plan and build the right thing?"
DevOps answers: "How do we deliver it safely, quickly, and reliably?"

Agile without DevOps = well-planned software that takes 3 months to reach users.
DevOps without Agile = fast pipelines deploying random, unplanned work.

💡 Key Insight

Agile and DevOps are complementary, not competing. Agile gives you the cadence (sprints, feedback loops). DevOps gives you the capability (automation, fast pipelines). Together they deliver value to users continuously.

Part 1 of 5 — continued

The Agile Manifesto — still relevant in 2025

The 4 Agile Values (2001)

Individuals & interactions over processes & tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

⚠ Common Misconception

"Agile means no documentation and no planning." Wrong. The manifesto says "over" — not "instead of." Documentation and planning still matter — just don't let them block delivery.

DevOps brings Agile to Life

Each Agile value maps directly to DevOps practice:

Individuals & interactions → Shared on-call, blameless culture, Dev+Ops in same standup
Working software → CI/CD ensures every commit produces a deployable artifact
Customer collaboration → Feature flags allow production testing with real users
Responding to change → Automated pipelines let you ship fixes in minutes, not months

The Ultimate Goal

Agile + DevOps together = continuous delivery of customer value. Small, frequent releases. Fast feedback. Rapid response to market changes.

Part 2 of 5

Scrum — the most widely used Agile framework

PRODUCT BACKLOG

All stories & tasks prioritised by Product Owner

→

SPRINT PLANNING

Select stories for 2-week sprint. Include infra & pipeline tasks!

→

SPRINT (2 weeks)

Daily standups. Dev + Ops work together.

→

SPRINT REVIEW

Demo must show deployed feature. Not just merged code!

→

RETROSPECTIVE

Review DORA metrics. What slowed delivery this sprint?

Scrum Roles

Product Owner: Prioritises backlog, defines acceptance criteria, represents customer
Scrum Master: Removes blockers, facilitates ceremonies, protects team from interruptions
Dev Team: Cross-functional — devs, testers, AND Ops engineers together

Scrum Artifacts

Product Backlog: Master ordered list of all work (features, bugs, tech debt, infra tasks)
Sprint Backlog: Subset selected for this sprint
Increment: The potentially shippable product at sprint end — must be deployable!

DevOps Additions

Add to standup: "Any pipeline or infra blockers?"
Include in backlog: CI/CD tasks, monitoring setup, security scanning, IaC updates
Review DORA metrics in every retrospective
Definition of Done = deployed + monitored

Part 2 of 5 — continued

Scrum Ceremonies — DevOps perspective

Ceremony	When	Traditional Focus	DevOps Addition
Sprint Planning	Start of sprint	Feature stories, estimation	Include pipeline tasks, infra work, tech debt in backlog. Ops engineer in the room.
Daily Standup	Every day, 15 min	What did I do? What will I do? Blockers?	4th question: "Any CI/CD or infra blockers?" Failed builds surfaced immediately.
Sprint Review	End of sprint	Demo features to stakeholders	Demo must be a live deployment — not "it works locally." Show the running URL in staging or production.
Retrospective	After review	What went well? What to improve?	Review DORA metrics trend. Ask: "Did our lead time improve? Any deployments fail?" Track engineering health.

💡 The Sprint Review Rule

If a feature is coded, tested, and merged but not deployed — it does not count toward the sprint velocity. "Done" in a DevOps team means deployed + healthy in production. This one change transforms team behaviour dramatically.

Part 2 of 5 — continued

Redefining "Done"

Traditional "Done"

✗ Code is merged to main
✗ QA has approved the story
✗ Product Owner has signed off
✗ Deployment scheduled for "next release"
✗ No monitoring set up
✗ No rollback plan documented

⚠ The Hidden Cost

Work "done" but not deployed still carries risk and maintenance cost. Undeployed code is inventory — it depreciates. Every day it sits undeployed, the risk of a difficult merge or stale context grows.

DevOps Definition of "Done"

✅ Code is reviewed and merged
✅ All CI checks pass (lint, test, security scan)
✅ Docker image built and pushed to registry
✅ Deployed to staging — smoke tested
✅ Deployed to production (or feature-flagged)
✅ Monitoring dashboard shows healthy metrics
✅ Rollback tested or documented
✅ Relevant documentation updated

The Lean Principle

Undeployed code = inventory. In Lean manufacturing, excess inventory is waste. In software, undeployed features are waste. Ship small, ship often, ship safely.

Part 3 of 5

Kanban — perfect for Ops and support work

Why Kanban for Ops?

Ops work is unpredictable — incidents, support tickets, security patches arrive randomly. Scrum's 2-week sprint commitment doesn't fit this reality well.

Kanban has no sprint commitments — work flows continuously
Pull-based: team pulls new work when capacity is free
WIP limits prevent overloading and context-switching
Cycle time (not velocity) is the key metric

Key Kanban Concepts

WIP Limit: Max items allowed in a column. Prevents bottlenecks and multitasking. e.g., "In Progress: max 3"
Cycle Time: Time from "started" to "done." Lower is better. The primary KPI.
Flow Efficiency: % of time work is actively progressed vs waiting
Pull System: Don't push work to people — they pull when ready

BACKLOG ∞

P1
Setup monitoring alerts for prod DB

INFRA
Upgrade nginx to 1.26

SEC
Rotate expired API keys

IN PROGRESS Max 3

DEVOPS
Add Trivy scan to CI pipeline

FEAT
Implement health endpoint

REVIEW Max 2

PR
Dockerfile optimisation — multi-stage

DONE ✓

DONE
Setup Git branch protection rules

💡 Lab Preview

You'll build exactly this board in GitHub Projects in today's lab — with custom columns, WIP limits, and your course day cards.

Part 3 of 5 — continued

Scrum vs Kanban — when to use which

Dimension	🔵 Scrum	🟣 Kanban
Cadence	Fixed sprints (1–4 weeks)	Continuous flow — no sprint boundaries
Planning	Sprint planning upfront — commit to scope	Just-in-time — pull next priority item when ready
Roles	Defined: PO, SM, Dev Team	No prescribed roles — team defines workflow
Key metric	Velocity (story points per sprint)	Cycle time (how long each item takes)
WIP limits	Implicit (sprint scope acts as limit)	Explicit column limits — visible and enforced
Best for	Feature development with predictable scope	Ops work, support, maintenance, on-call tasks
Change policy	No changes mid-sprint (protect the team)	Add new work anytime — just prioritise it

Real-World Hybrid — "Scrumban"

Many teams use a hybrid: Scrum for feature development (Dev team) + Kanban for operations (Ops/SRE team). The two boards co-exist. High-priority incidents can be pulled from Kanban without disrupting the sprint. This is extremely common in mature DevOps organizations.

Part 4 of 5

DORA Metrics — inside the sprint cycle

Tracking DORA in Retrospectives

Add 5 minutes to every sprint retrospective to review DORA trends:

Deploy Frequency: "How many times did we deploy this sprint? Are we trending up?" Target: every feature in its own deployment
Lead Time: "What was the slowest story? What caused the delay?" Find the bottleneck
Change Failure Rate: "Did any deployments cause incidents? What was the root cause?"
MTTR: "If there was an incident, how fast did we recover? Was runbook up to date?"

Sprint Backlog Items DevOps Teams Add

Don't just put features in the backlog. Include:

🔧 Tech debt: "Upgrade deprecated npm packages"
🛡 Security: "Add Trivy scan to CI pipeline"
📊 Observability: "Add Prometheus metrics to payments service"
🏗 IaC: "Migrate staging server config to Terraform"
📝 Runbooks: "Document DB failover procedure"
🔄 Pipeline: "Add staging deploy step to CI workflow"

💡 Rule of Thumb

If Ops work doesn't go into the backlog, it doesn't get prioritised, estimated, or tracked. Result: tech debt accumulates and DORA metrics stagnate.

Part 4 of 5 — continued

Writing DevOps-Ready User Stories

❌ Typical Story (Incomplete)

"As a user, I want to log in with my email and password so that I can access my account."

Acceptance criteria:

Login form shows email + password fields
Successful login redirects to dashboard
Invalid credentials show error message

Missing: deployment criteria, monitoring, security testing, rollback plan

✅ DevOps-Ready Story

"As a user, I want to log in with my email and password so that I can access my account."

Acceptance criteria:

Login form shows email + password fields
Successful login redirects to dashboard
Invalid credentials show error message

DevOps acceptance criteria (Definition of Done):

✅ Unit tests cover happy path + invalid credential cases (>80% coverage)
✅ SAST scan shows no high/critical security issues
✅ Feature deployed to staging and smoke tested
✅ Deployed to production (or behind feature flag)
✅ Login success/failure rate tracked in Grafana

Part 5 of 5

🔧 Hands-On Lab

Set up a GitHub Project Board — your Kanban command centre for all 35 days of this course

⏱ 25 minutes

Needs: GitHub account ✓

No installs required

🔧 Lab — Step by Step

Build your course Kanban board

1

Create a new GitHub Project

Go to github.com → Your profile → Projects → New project → Select "Board" template. Name it: "DevOps 35-Day Journey". Set visibility to Public (optional).

2

Create 5 columns with WIP limits

Rename default columns and add two more: Backlog (no limit) → This Week (max 5) → In Progress (max 3) → Review / Blocked (max 2) → Done. Set WIP limits using column settings.

3

Add cards for Days 4–35

Create one card per remaining day with the day title. Example: "Day 4 — Linux for DevOps", "Day 5 — Networking for DevOps". Place all in Backlog. Move Day 4 to "This Week".

4

Add labels and custom fields

Add a custom field: Week (single select: W1, W2... W8). Add labels per card: theory, lab, jenkins, docker, kubernetes, ansible. This makes filtering easy.

5

Link board to your lab repository

In the Project settings, add your devops-35days-labs repo as a linked repository. Now GitHub Issues and PRs from that repo automatically appear as project cards. Mark Day 3 Done!

🔧 Lab — Definition of Done Template

Your course DoD template

markdown — .github/COURSE_DOD.md

# Course Definition of Done
# Add this to your devops-35days-labs repo

## Each Day is "Done" When:
- [ ] Theory slides reviewed (all sections opened)
- [ ] Hands-on lab completed
- [ ] Lab code committed to devops-35days-labs
- [ ] All 3 quiz questions attempted
- [ ] Day marked complete in course app
- [ ] Key takeaway noted in README

## Lab Commit Convention:
# feat(dayN): description of lab work
# e.g. feat(day3): add GitHub Project kanban board
# e.g. feat(day6): implement git branching workflow
# e.g. lab(day11): create github actions ci pipeline

## Board Columns + WIP Limits:
# | Backlog | This Week | In Progress | Review | Done |
# |   ∞     |   max 5   |   max 3     | max 2  |  ✓   |

markdown — Sample card template

## Day 11 — CI/CD Concepts & Jenkins
**Week:** Week 3
**Label:** jenkins, ci-cd, theory

### Theory Topics
- [ ] CI vs CD vs Continuous Deployment
- [ ] Pipeline anatomy (stages, jobs, steps)
- [ ] Jenkins vs GitHub Actions comparison
- [ ] Jenkins architecture (controller/agent)

### Lab
- [ ] Write first GitHub Actions workflow
- [ ] Write equivalent Jenkinsfile
- [ ] Compare syntax side by side

### Quiz
- [ ] 3 questions completed

### DoD
- [ ] Code committed: feat(day11): ci pipeline lab
- [ ] Card moved to Done ✓

💡 Power Feature

Link GitHub Issues from your lab repo to project cards. When you create a PR with "closes #issue-number", the card automatically moves to Done. Your Kanban board becomes a live view of your learning progress.

🔧 Lab — Bonus Exercise

Simulate a DevOps sprint

Mini Sprint Planning (10 min)

Treat the next 7 days of this course as a sprint. Pick 7 days from your Kanban Backlog and move them to "This Week". For each, write:

What is the goal of this day? (1 sentence)
What is the deliverable? (lab output)
What are the risks? (tool install issues, prerequisite knowledge)

This trains sprint planning thinking — estimating effort before starting.

Mini Retro Checklist (End of each week)

At the end of each week, spend 10 minutes on a self-retro:

✅ How many days did I complete this week?
✅ What was the hardest concept? (note it)
✅ What lab took longest? Why?
✅ What would I do differently next week?
✅ What is my DORA improvement target for next week?

Metacognition

The best DevOps engineers are continuous learners. Retrospecting on your own learning process — not just your work — is a superpower.

Knowledge Check

❓ Quiz Time

3 questions · 5 minutes · Instant feedback

Test your Agile + DevOps understanding →

QUESTION 1 OF 3

In a DevOps-aligned Scrum team, when is a user story considered "Done"?

A

When the code is merged to the main branch

B

When the QA team approves the story in staging

C

When the feature is deployed to production and monitored as healthy

D

When the Product Owner signs off on the user story

QUESTION 2 OF 3

Which Agile framework is best suited for Ops and on-call work with unpredictable incoming tasks?

A

Scrum with 2-week sprints

B

Kanban with WIP limits and cycle time tracking

C

SAFe (Scaled Agile Framework)

D

Waterfall with change control board

QUESTION 3 OF 3

What DevOps addition should be made to Sprint Planning that is missing in traditional Scrum?

A

More detailed technical documentation for each story

B

A separate planning meeting for Ops engineers only

C

Reducing sprint length to 1 week

D

Include infrastructure, pipeline, monitoring, and security tasks in the backlog alongside feature stories

Day 3 — Complete

What you learned today

🤝

Agile vs DevOps

Agile = how we plan. DevOps = how we deliver. Inseparable partners.

🔄

Scrum + DevOps

Add infra tasks to backlog. Demo deployed features. Review DORA in retros.

📋

Kanban for Ops

WIP limits + cycle time = the ops team's cadence. Continuous flow beats sprints for unpredictable work.

✅

Done = Deployed

Merged ≠ Done. Deployed + monitored + healthy = Done. This one change transforms delivery.

Day 3 Action Items

GitHub Project board created with 5 columns + WIP limits
All 35 day cards added to Backlog
Add .github/COURSE_DOD.md to your lab repo
Move Days 4–8 to "This Week" — your first sprint!

Tomorrow — Day 4

Linux for DevOps

File system, permissions, shell scripting, and the 20 Linux commands every DevOps engineer uses daily. Your first shell script that prints system info.

Terminal bash chmod grep tail -f