Agile Development and Scrum

Two Teams, One Deadline

Two teams of Class 9 students are each asked to build a "Lost & Found" web app for their school, due in eight weeks. Whoever finds a missing item can post a photo and location; whoever lost it can search and claim it.

Team A does what feels responsible: they spend the first three weeks writing a complete requirements document, then two weeks designing every screen, then three weeks coding the entire app in one continuous push. Nobody outside the team sees a single working screen until week eight, when they finally demo it to their teacher-in-charge. The teacher tries it for thirty seconds and says, "Where's the part where a teacher approves a claim before an item is released? Anyone could just say 'that's mine.'" Team A never asked this question during their three-week requirements phase, because nobody thought to check with the actual users until the plan was "finished." Fixing it now means reopening the login system, the database structure, and the claim workflow — three weeks of rework, with only zero weeks left.

Team B works differently. In their first two weeks, they build the smallest possible working slice: a student can post one photo with a description, and another student can see it in a list. It is ugly and does almost nothing else, but it runs, and they show it to the teacher-in-charge immediately. That five-minute conversation surfaces the approval problem in week two, not week eight. Team B adds an "approval by staff" step to their plan for the very next two-week block. Every two weeks, they show a slightly more complete, still-working app to real users, catch misunderstandings while they are cheap to fix, and finish week eight with something the school actually wants to use.

Both teams worked hard. Both teams knew how to code. The difference was not skill — it was how they organised the act of building software over time. Team A followed what software engineers call the Waterfall model. Team B followed the ideas behind Agile development, using a specific framework called Scrum. This chapter is about exactly what Team B did differently, and why it is not just "working faster" but a genuinely different way of thinking about building software.

Why the Waterfall Model Breaks When Requirements Change

Every software project has a life cycle: someone figures out what to build (requirements), someone plans how it will be built (design), someone writes the code (implementation), someone checks it works (testing), and someone keeps it running afterward (maintenance). This sequence is called the Software Development Life Cycle (SDLC), and every model you study — Waterfall, Iterative, Spiral, Agile — is really just a different answer to one question: in what order and rhythm do we move through these stages?

The Waterfall model, one of the earliest structured approaches, answers that question by insisting each stage finishes completely before the next one begins — like water falling down a series of steps, never flowing back up. You cannot start coding until the design is signed off. You cannot start designing until every requirement is documented. This is not a bad idea in principle: it forces discipline, and for projects where the requirements truly are fixed and well understood in advance — say, software that controls a satellite's orbital thrusters, where a mistake is catastrophic and the physics does not change its mind halfway through — that rigidity is a genuine strength.

The trouble is that most software projects are not like that. The people asking for the software often cannot fully describe what they want until they see something running — this is a well-documented pattern in software engineering, not a character flaw of Team A's teacher. Waterfall has no built-in mechanism for feedback until the very end, because feedback requires something working, and in Waterfall nothing works until nearly everything is built. Every misunderstanding discovered late is expensive to fix, because fixing it means walking back up steps that were designed to only flow downward.

The Agile Manifesto: Four Values

In February 2001, seventeen software practitioners met at a ski resort in Snowbird, Utah, specifically to discuss what they saw going wrong with heavyweight, documentation-first processes like Waterfall. Out of that meeting came a short document called the Agile Manifesto, which states four values. Each value is written as "X over Y" — meaning both X and Y matter, but when they conflict, X wins:

• Individuals and interactions over processes and tools — a team that talks to each other solves problems faster than one that only follows a flowchart.
• Working software over comprehensive documentation — a running app that does three things beats a 200-page specification for an app that does nothing yet.
• Customer collaboration over contract negotiation — checking in with the actual user regularly catches misunderstandings early, instead of only at a final "acceptance" meeting.
• Responding to change over following a plan — if you learn something new in week three, the plan should bend, not the reality.

Notice what these values do not say. They do not say "no documentation" or "no planning" or "no process." They say that when documentation and running software are in tension, running software wins; when a rigid plan and new information are in tension, the plan should adapt. Agile is a set of priorities for resolving conflicts, not a rejection of structure — this distinction matters enough that we will return to it as a specific misconception later in this chapter.

Iterative and Incremental: Building in Slices, Not Layers

To act on those four values, Agile teams build software iteratively and incrementally. These two words are often used together but mean slightly different things, and mixing them up is a common source of confusion.

Incremental means the product grows by adding pieces, like assembling a machine part by part — each piece is complete and usable on its own. Iterative means you revisit and improve what already exists, refining it across repeated cycles, like sculpting a statue by going over the whole shape again and again, each pass adding more detail. Agile development typically does both at once: in Team B's Lost & Found app, "post a photo and see a list" was one increment (a new capability added), and when they later improved that same list to support searching and filtering, that was iteration (refining something that already existed).

Contrast this with how Waterfall builds a product: imagine building a house where you complete 100% of the foundation, then 100% of the walls, then 100% of the roof, then 100% of the plumbing — you cannot live in the house or even see if the rooms feel right until every layer is entirely finished. An Agile team instead builds one complete, tiny room first — foundation, walls, roof, and plumbing, all present but on a small scale — so someone can walk into it and say "actually, I wanted the door on the other side" while moving one door is still cheap.

Scrum: A Specific Framework for Practicing Agile

"Agile" is a philosophy — a set of values and principles. It does not, by itself, tell you exactly what meetings to hold or what roles people should play. Scrum is the most widely used concrete framework that puts Agile values into practice with specific rules. It was formalised by Jeff Sutherland and Ken Schwaber in the mid-1990s, who borrowed the name from rugby football. In rugby, a scrum is a formation where players from both teams pack tightly together, link arms, and drive forward as one unit to restart play — a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka had used this image to describe cross-functional teams that move the whole product forward together, rather than passing work down a chain from one specialist to the next. That is exactly the picture Scrum wants for a software team: not "the designer finishes, then hands off to the coder, who hands off to the tester," but a small group that plans, builds, and checks together, in tight, repeated cycles.

Scrum organises a team's work using three kinds of things: roles (who does what), artifacts (what gets produced and tracked), and events (the recurring meetings that structure time). We will go through each.

The Three Scrum Roles

• Product Owner — the single person responsible for deciding what gets built and in what order. The Product Owner represents the users and stakeholders (in our example, the teacher-in-charge and the students who lose things), and keeps a prioritised wish list of everything the product could ever do.
• Scrum Master — not a project manager who assigns tasks, but a facilitator who protects the team's process: running the meetings, removing obstacles (a blocked school Wi-Fi login, a confusing requirement), and making sure the team actually follows Scrum's rules instead of quietly sliding back into ad-hoc chaos or secretly-Waterfall habits.
• Development Team — the people who actually design, code, and test the increment each cycle. In Scrum, this team is deliberately cross-functional and self-organising: it decides how to build what the Product Owner asked for, rather than being told task-by-task by a manager.

A common mistake is imagining these as ranks, with the Scrum Master as "boss" of the Development Team. They are not a hierarchy — they are three different jobs needed to keep the cycle running, and in a small student team the same two or three people might rotate through more than one role across different sprints.

The Scrum Artifacts

• Product Backlog — the complete, ordered list of everything that could be built: features, fixes, improvements. It is never "finished"; the Product Owner keeps reordering it as priorities and understanding change.
• Sprint Backlog — the small subset of Product Backlog items the Development Team commits to finishing in the upcoming cycle, plus their plan for doing it.
• Increment — the sum of everything completed so far, in a state that actually works. At the end of every cycle, the Increment must meet the team's agreed Definition of Done (for example: "code written, tested, and running on the school server" — not "mostly written, will finish testing next time").

The Sprint: A Fixed Time-Box

The heartbeat of Scrum is the Sprint — a fixed period, almost always somewhere between one and four weeks (two weeks is the most common choice in practice), during which the Development Team builds a working Increment from items in the Sprint Backlog. The critical word is fixed: once a Sprint's length is set, it does not stretch. This is exactly like a T20 cricket innings — twenty overs is twenty overs, whether a team has scored 40 runs or 190 when the last ball is bowled. A Sprint works the same way: if the team only finishes half the Sprint Backlog, the Sprint still ends on schedule. The unfinished items go back into the Product Backlog to be reprioritised, not to an "extended sprint." This fixed rhythm is what makes progress measurable and predictable — you always know exactly when the next checkpoint arrives.

Within every Sprint, three more events happen:

• Sprint Planning — at the start, the whole team meets to select items from the Product Backlog for this Sprint's Sprint Backlog, and roughly plans how to build them.
• Daily Scrum — a short (about fifteen minutes), same-time-every-day check-in where each team member answers three questions: what did I finish since yesterday, what will I work on today, and is anything blocking me? This is not a status report to a boss — it is the team synchronising with itself, so a blocker like "I can't get the photo upload working" surfaces on day three instead of being discovered on day ten.
• Sprint Review — at the end, the team demonstrates the actual working Increment to the Product Owner and stakeholders (the teacher-in-charge, in our story) and gathers feedback, which feeds directly into the next round of Product Backlog prioritisation.
• Sprint Retrospective — held right after the Review, just for the team: what went well this Sprint, what slowed us down, and what will we change next time? This is where the team's process itself improves, cycle over cycle.

Put together, these events and artifacts form a repeating cycle. The diagram below shows how they connect.

Read the diagram as a loop: the Product Owner's Backlog feeds Sprint Planning, which locks in a Sprint Backlog; the Development Team spends the Sprint building inside daily check-ins; the result is an Increment; that Increment is shown at the Sprint Review, which usually adds new items or reorders the Product Backlog based on feedback; the team then holds a Sprint Retrospective on their own process; and the loop closes straight back into the Product Backlog for the next Sprint. Every full lap through this loop takes one Sprint.

Worked Example: From Product Backlog to Sprint Backlog

Suppose Team B's Product Owner has written down four Product Backlog items for the Lost & Found app, each estimated in story points — a relative unit of effort the team agrees on together (not hours; a study session with your friends where you all guess "how hard is this compared to that other task" is a good mental model). Larger numbers usually come from a Fibonacci-like sequence (1, 2, 3, 5, 8, 13...) precisely because it is hard to be falsely precise about the difference between an 8 and a 9, but easy to agree that an 8 is clearly bigger than a 5.

Here is that backlog, and a very simplified way to model "what can we fit in this Sprint if our capacity is 13 points":

product_backlog = [
    {"item": "Login with school ID", "priority": 1, "points": 5},
    {"item": "View today's homework", "priority": 2, "points": 3},
    {"item": "Upload photo of notebook", "priority": 3, "points": 8},
    {"item": "Push notification reminder", "priority": 4, "points": 5},
]

sprint_capacity = 13
sprint_backlog = []
used = 0

for task in sorted(product_backlog, key=lambda t: t["priority"]):
    if used + task["points"] <= sprint_capacity:
        sprint_backlog.append(task["item"])
        used += task["points"]

print(sprint_backlog)
print("Points committed:", used)

Trace it by hand, the way you would on an answer sheet. The list is sorted by priority, so we look at items in this order: "Login with school ID" (5 points), "View today's homework" (3 points), "Upload photo of notebook" (8 points), "Push notification reminder" (5 points). Start with used = 0. Item 1: 0 + 5 = 5, which is <= 13, so it's added; used becomes 5. Item 2: 5 + 3 = 8, which is <= 13, so it's added; used becomes 8. Item 3: 8 + 8 = 16, which is not <= 13, so it is skipped — it stays in the Product Backlog for a future Sprint. Item 4: 8 + 5 = 13, which is <= 13, so it's added; used becomes 13. The program prints:

['Login with school ID', "View today's homework", 'Push notification reminder']
Points committed: 13

This is a simplified model of what real Sprint Planning does by discussion rather than by a fixed rule: the team looks at priority order and its own realistic capacity, and commits to what it can actually finish — not everything the Product Owner might wish for.

Velocity: Turning Past Sprints Into a Forecast

After a few Sprints, a team can measure its velocity: the average number of story points it actually completes per Sprint. Velocity is not a target to hit — it is a measurement, used honestly, to make realistic promises about the future.

Suppose Team B completed 18 story points in Sprint 1, 22 in Sprint 2, and 20 in Sprint 3. Their Product Backlog now has 100 points of remaining work. How many more Sprints will it likely take?

import math

sprint_points_completed = [18, 22, 20]

def average_velocity(completed):
    return sum(completed) / len(completed)

def sprints_needed(backlog_points, velocity):
    return math.ceil(backlog_points / velocity)

v = average_velocity(sprint_points_completed)
remaining_backlog = 100

print("Average velocity:", v)
print("Sprints needed for remaining backlog:", sprints_needed(remaining_backlog, v))

Trace this line by line. sum(sprint_points_completed) is 18 + 22 + 20 = 60. len(sprint_points_completed) is 3. So average_velocity returns 60 / 3 = 20.0, and v is 20.0. Then sprints_needed(100, 20.0) computes 100 / 20.0 = 5.0, and math.ceil(5.0) is 5 (rounding up to the next whole Sprint; if the division had given, say, 4.3, we would still need a full 5th Sprint to finish the fractional remainder). The output is:

Average velocity: 20.0
Sprints needed for remaining backlog: 5

This is exactly how a Product Owner gives a realistic answer to "when will it be done?" — not by guessing, but by measuring what the team has actually delivered in the past and projecting it forward. It is also honest about uncertainty: velocity is an average of past performance, not a guarantee, which is why good forecasts are given as a range rather than a single date.

Tracking Progress Inside a Sprint: The Burndown Chart

Velocity tells you about Sprints as whole units. A burndown chart tracks progress during a single Sprint, day by day, so blockers are visible immediately instead of only at the Sprint Review.

Suppose a different Team's Sprint Backlog totals 40 story points over a 10-working-day, two-week Sprint. If work went perfectly evenly, the "ideal" line would drop by exactly 4 points every day: 40, 36, 32, 28, 24, 20, 16, 12, 8, 4, 0. Real work rarely burns down in a straight line. Here is what actually happened: the team completed 3 points on day 1, 4 on day 2, then hit a blocker on day 3 (a database connection that would not authenticate) and completed 0 that day — flagged immediately at the day 3 Daily Scrum, not discovered later. They recovered with 5 points on day 4 and 4 on day 5, lost another day to a school event on day 6 (0 points again), and then, having learned the codebase well by that point, closed strong with 6 points on each of days 7 through 10.

Remaining work at the end of each day is therefore: 40, 37, 33, 33, 28, 24, 24, 18, 12, 6, 0. The chart below plots both lines.

Notice the two flat stretches in the red line, on days 3 and 6 — those are the blocker and the school event, visible as a lack of downward movement. In Waterfall, a comparable stall might not be discovered until the final demo, when it is far too late to recover. In Scrum, because the Daily Scrum forces the team to say out loud "I made no progress today because of X," the flat line is spotted after a single day, and the Scrum Master can start clearing the blocker immediately rather than after eight weeks.

Common Misconception: "Agile Means No Planning or Documentation"

Students often hear "Agile welcomes change" and "working software over documentation" and conclude that Agile teams just start coding without a plan. This is incorrect, and it is worth stating precisely why. Sprint Planning is itself a planning meeting, held every single Sprint — an Agile team plans far more often than a Waterfall team, not less. What Agile actually rejects is a single, giant, upfront plan that is assumed to survive unchanged for the rest of the project. Agile replaces one long plan with many short, cheap-to-revise plans, made with better information each time because each new Sprint's plan is informed by what was actually learned in the last one. Documentation still happens — a Definition of Done, a backlog, sometimes design notes — but only as much as is genuinely useful for building working software, not as an end in itself.

A second, related misconception is worth naming: some students assume "Agile" and "Scrum" are the same word for the same thing. Agile is the underlying philosophy — the four values and their supporting principles. Scrum is one specific, popular framework for practicing that philosophy, with its own named roles, artifacts, and events, as described above. Other frameworks put the same Agile values into practice differently — for instance, Kanban, which uses a continuously updated board of columns like "To Do," "In Progress," and "Done," pulls in new work item-by-item as capacity frees up, and has no fixed Sprint length at all. A team can be genuinely Agile while using Scrum, Kanban, or another framework; "Agile" describes the destination and its values, while "Scrum" is one specific vehicle for getting there.

CBSE Exam Keywords

These terms are the ones most likely to appear as one-line definitions or short-answer questions:

• SDLC (Software Development Life Cycle) — the ordered stages every software project passes through: requirements, design, implementation, testing, maintenance.
• Waterfall model — an SDLC model where each stage must fully complete before the next begins, with no planned return to an earlier stage.
• Agile Manifesto — the 2001 document stating four values that prioritise people, working software, collaboration, and adaptability over rigid process, exhaustive documentation, fixed contracts, and fixed plans.
• Iterative development — repeatedly revisiting and refining existing parts of a product across cycles.
• Incremental development — building a product by adding complete, usable pieces one at a time.
• Scrum — a specific Agile framework with defined roles (Product Owner, Scrum Master, Development Team), artifacts (Product Backlog, Sprint Backlog, Increment), and events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective).
• Sprint — a fixed, time-boxed period (commonly two weeks) in which a working Increment is built.
• Story point — a relative, team-agreed unit for estimating the effort of a backlog item, often using a Fibonacci-like scale.
• Velocity — the average number of story points a team completes per Sprint, used to forecast future delivery.
• Burndown chart — a day-by-day graph of remaining work in a Sprint, comparing actual progress against an ideal straight-line pace.
• Definition of Done — the team's agreed checklist for when a backlog item can be counted as genuinely, fully complete.

Check Your Understanding

1. Team A and Team B both had eight weeks and equally skilled coders, yet Team A had to redo major parts of their app. In one or two sentences, explain the structural reason this happened — not "Team A was careless," but what about their process caused it.
2. A Product Backlog item is estimated at 8 story points. Does that mean the task will take exactly 8 hours? Explain what story points actually measure.
3. A team's Sprint Backlog totals 30 points over a 10-day Sprint, and the ideal burndown line is a perfectly straight diagonal. On day 5, the team's actual remaining work is still 24 points (only 6 completed). Is this necessarily a crisis? What should happen at the very next Daily Scrum?
4. A team completed 15, 17, and 19 story points in three consecutive Sprints. Using the same method shown in the velocity code example, calculate their average velocity and estimate how many more Sprints are needed to clear a 90-point remaining backlog.
5. Explain, in your own words, why "Agile means no documentation" is an incorrect statement, using the idea of Sprint Planning in your answer.
6. Give one difference between Scrum and Kanban that is not just "Scrum has a rugby-related name."

Answer notes: (1) Waterfall requires each stage to fully finish before the next starts, so there was no working software to show the teacher until the very end — the misunderstanding about staff approval could only be caught after nearly all the code was already written, making the fix expensive. (2) No — story points measure relative effort and complexity compared to other backlog items, agreed on by the team, not a promise of clock hours. (3) Not automatically a crisis — a single slow day happens; the Daily Scrum should surface honestly what is blocking progress (as in the burndown example's day 3 and day 6 flat stretches) so the Scrum Master can act on it immediately rather than waiting for the Sprint Review. (4) Average velocity = (15+17+19)/3 = 51/3 = 17.0; sprints needed = ceil(90/17.0) = ceil(5.29) = 6 Sprints. (5) Sprint Planning is itself a full planning meeting held at the start of every single Sprint, so Agile teams plan continuously in small, frequently-updated pieces rather than not planning at all — "over comprehensive documentation" means documentation is not prioritised above a working product, not that documentation or planning is banned. (6) Scrum uses fixed-length, time-boxed Sprints with defined roles and ceremonies; Kanban is a continuous flow with a visual board and work-in-progress limits, and has no fixed iteration length at all.

Summary

The Waterfall model builds software in strictly ordered, non-overlapping stages, which works well when requirements are fixed and understood in advance but breaks down expensively when they are not — because nothing is shown to real users until nearly everything is built. The Agile Manifesto, written in 2001, responds to this by valuing individuals and interactions, working software, customer collaboration, and responsiveness to change over rigid process, exhaustive documentation, fixed contracts, and fixed plans — without rejecting planning or documentation altogether. Agile teams build iteratively and incrementally, in small, working slices shown to real users repeatedly rather than once at the end. Scrum is the most widely used framework for practicing Agile: it defines three roles (Product Owner, Scrum Master, Development Team), three artifacts (Product Backlog, Sprint Backlog, Increment), and a repeating cycle of events (Sprint Planning, Daily Scrum, the Sprint itself, Sprint Review, Sprint Retrospective) built around a fixed time-box called the Sprint. Story points give teams a relative way to estimate effort; velocity turns completed story points into an honest forecast for future work; and burndown charts make day-by-day progress — and stalls — visible while there is still time to act on them, which is the entire point of moving away from Waterfall in the first place.