Agile Methodology: How Real Teams Build Software

Imagine your school's Computer Club is asked to build an app for the annual Tech Fest — students should be able to register for events, pick a time slot, and pay the entry fee. The club decides to do it the "serious" way: spend three weeks writing down every single feature the app will ever need, get it approved by the Fest committee, and then disappear into a room and code for two months without showing anyone anything until the app is "finished."

Two months later, the club proudly unveils the app. The committee looks at it and says: "Wait — we changed the rules last month. There are now five events per student instead of three, and we need a QR-code entry pass, not just a confirmation screen." The payment screen the club spent a week perfecting is now useless, because the fee structure changed too. Three weeks of design documents are outdated. The team has four days left before the fest, and they are rebuilding half the app under panic.

This is not a made-up disaster story — it is, almost exactly, the failure pattern that real software companies lived through for decades, and it is the reason a group of experienced programmers eventually sat down and asked: what if we built software in small, working slices instead of one giant slice at the very end? That question is where Agile methodology comes from, and this chapter builds up the whole idea from that one insight.

The old way: the Waterfall model

The Computer Club's approach has a name: the Waterfall model. In Waterfall, a software project moves through fixed phases, one after another, like water falling down a series of steps — you never go back up.

1. Requirements — write down everything the software must do, completely, before any code is written.
2. Design — plan the architecture and screens based on those requirements.
3. Implementation — write the actual code.
4. Testing — check that the finished product matches the requirements.
5. Deployment — release it to real users.

Waterfall is not a foolish idea — it works reasonably well for projects where requirements genuinely will not change, like the control software for a bridge's traffic lights, where the rules of traffic are stable and well understood in advance. But for most software — apps, websites, games — the people asking for the software often do not fully know what they want until they see a working version of it. Waterfall assumes you can get the requirements perfectly right at the very start and that nothing about the world will change while you build. Real projects rarely satisfy that assumption, and when reality breaks it, the cost of fixing a requirement discovered late is enormous: you may have to redo design documents, rewrite code, and redo testing, all after most of the schedule is already spent.

The core idea: build in small, working slices

Agile methodology fixes this by changing the fundamental shape of the work. Instead of one long sequence of Requirements → Design → Build → Test → Deploy spread across months, Agile breaks the same journey into many short, repeating cycles — each cycle produces a small but genuinely working piece of the product, which real users or stakeholders can see and react to immediately.

Go back to the Tech Fest app. An Agile version of the Computer Club would not spend three weeks writing a complete specification. Instead, in the very first week, they would build the smallest useful slice — say, just "a student can register their name and pick one event" — and show it to the Fest committee. The committee's feedback ("we actually need five events per student") arrives in week one, not week eight, when it costs almost nothing to absorb. Each following week adds another slice — payment, QR passes, slot booking — and each slice is checked against reality before the next one is built on top of it.

The diagram below makes the structural difference concrete: Waterfall is one long line with feedback arriving only at the very end; Agile is a repeating loop where feedback arrives after every short cycle.

Where Agile actually came from

Agile is not one company's invention or one specific tool — it is a shared set of values that a group of seventeen experienced software practitioners wrote down together in February 2001, at a meeting in Snowbird, Utah. They had each been experimenting, independently, with lighter, faster, more feedback-driven ways of building software, and they discovered their approaches shared a common spirit. They published this as the Manifesto for Agile Software Development, built around four value statements. In their own words, they said they valued: people and the way they interact with each other more than rigid processes and tools; software that actually works more than exhaustive paperwork about the software; working together with the customer more than arguing over a fixed contract; and staying ready to change direction more than blindly sticking to the original plan. Importantly, the manifesto does not say tools, documentation, contracts, and plans are worthless — it says that when the two are in tension, the item on the left should win.

They backed this up with twelve supporting principles. A few of the most important for you to know: deliver working software frequently, in periods of weeks rather than months; welcome changing requirements even late in a project, because Agile treats change as a competitive advantage rather than as a threat to be avoided; have businesspeople and developers work together daily throughout the project, not just at the start and end; and hold regular reflection sessions where the team tunes how it works. Agile, at its core, is this mindset — it is a set of values and principles, not a step-by-step procedure. To actually run a project, teams use a concrete framework that puts these values into practice. The most widely used one is called Scrum, and understanding it in detail is how you understand Agile in practice rather than just in theory.

Scrum: a concrete framework for practicing Agile

Scrum organizes work into fixed-length iterations called sprints, typically two to four weeks long. Everything the team might ever build lives in a single ranked list called the Product Backlog — a to-do list of features, ordered by what matters most right now. At the start of every sprint, the team holds Sprint Planning: they pull the highest-priority items off the top of the Product Backlog and commit to finishing them in this sprint. This smaller, sprint-specific list is called the Sprint Backlog.

During the sprint, the team meets for about fifteen minutes every day in the Daily Scrum (often called a "standup," because it is kept short enough that people stay standing). Each person answers three things, briefly: 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 manager — it is the team synchronizing with itself.

At the end of the sprint, two things happen, and it is important not to confuse them. First is the Sprint Review: the team demonstrates the actual working software they built — not slides, the real thing — to the Product Owner and other stakeholders, and gathers feedback that reshapes the Product Backlog for future sprints. Second, separately, is the Sprint Retrospective: the team meets privately, without outsiders, to discuss how the sprint went as a process — what slowed us down, what should we try differently next sprint — and commits to one or two concrete improvements. Review looks at the product; Retrospective looks at the team's own way of working.

Three roles make this run. The Product Owner owns the Product Backlog and decides what matters most — they represent the customer's and users' interests and are the single person responsible for the backlog's priority order. The Scrum Master is not a boss; they are a facilitator who protects the team's process, runs the ceremonies, and removes obstacles ("blockers") the team reports in the Daily Scrum. The Development Team (sometimes just called "the Developers") is a small, self-organizing group — Scrum deliberately avoids assigning tasks top-down; the team decides among itself how to do the work it committed to.

User stories: how requirements get written in Agile

Instead of a giant requirements document, Agile teams describe features as short user stories, written from the point of view of the person who will actually use the feature. The standard template is:

As a <type of user>, I want <some goal>, so that <some benefit>.

For the Tech Fest app, the Computer Club's Product Backlog might contain stories like:

As a student, I want to register for an event using my roll number,
so that I don't have to fill in my details by hand every time.

As a Fest volunteer, I want to scan a student's QR pass at the entry gate,
so that I can check them in within a few seconds instead of searching a paper list.

As the Fest coordinator, I want to see how many seats are left per event in real time,
so that I can close registration before a room gets overcrowded.

Each story is small enough to be finished inside a single sprint, and each one names a real benefit — this keeps the team focused on why a feature matters, not just on building whatever was listed first. A story is only considered "done" when it meets agreed-upon acceptance criteria — specific, checkable conditions (for example: "registration fails with a clear error message if the roll number is not in the school database") that everyone agreed on before the sprint began.

Estimating work: story points, not hours

A natural question follows: how does a team know how much work it can fit into one sprint? Agile teams almost never estimate in hours, because humans are consistently bad at predicting exact hours, especially for creative work like coding. Instead, they estimate in story points — a number representing the story's relative size and difficulty compared to other stories, not a fixed unit of time.

Teams commonly use a Fibonacci-like scale for this: 1, 2, 3, 5, 8, 13, 21. The gaps get wider as the numbers get bigger on purpose — it is easy to be confident that a task is "about twice as hard" as another, but it is much harder to be confident about the exact difference between a 14 and a 15, so the scale simply stops offering that false precision. In a practice called planning poker, every team member privately picks a number card for a story and reveals it at the same time; if a developer picks 3 and another picks 13 for the same story, that big gap is valuable information — it usually means one of them knows about a hidden difficulty the other has not noticed, and the team discusses it before agreeing on a final number.

Once a team has run a few sprints, they can compute their velocity: the average number of story points they actually complete per sprint. This number turns into a genuinely useful planning tool. Suppose Team Avni, building the Tech Fest app, completed 28 story points in Sprint 1, 32 in Sprint 2, and 30 in Sprint 3. Their velocity is the average:

velocity = (28 + 32 + 30) / 3 = 90 / 3 = 30 story points per sprint

If the remaining Product Backlog totals 210 story points, the team can forecast how long the rest of the project will take:

sprints needed = 210 / 30 = 7 sprints

At two weeks per sprint, that is fourteen weeks. This is not a guarantee — velocity can change as the team learns or as story sizes turn out to be misjudged — but it is a far more honest forecast than guessing a finish date on day one of a Waterfall project, because it is built from the team's own measured, recent performance rather than from hope.

Tracking a sprint in progress: the burndown chart

Within a single sprint, teams track daily progress using a burndown chart: a simple line graph plotting story points remaining against the days of the sprint. If everything went exactly to plan, the line would fall in a straight diagonal from the total committed points down to zero on the last day — this is called the ideal line.

Suppose a sprint is ten working days long and the team committed to 40 story points. The ideal burndown removes 40 ÷ 10 = 4 points per day:

Reading this actual line against the ideal line tells a real story, not just a decorative graph: on Days 1–4 the actual line sits above the ideal line, meaning the team is behind — perhaps stories turned out harder than estimated, or the sprint started slowly. Between Day 4 and Day 5 the line drops sharply (33 to 25, an 8-point day), meaning the team caught up, likely because several stories finished together. By Day 10 both lines reach zero, so the sprint still finished on time. A team that sees its actual line staying stubbornly above the ideal line for several days in a row uses that as an early warning — not to work unpaid overtime, but to raise it at the Daily Scrum and possibly ask the Product Owner to remove a lower-priority story from the sprint, protecting quality over pretending everything is fine.

Kanban: the other major Agile framework

Scrum is not the only way to practice Agile values. Kanban, a technique adapted from Toyota's manufacturing floor and brought into software by David J. Anderson, takes a different approach: instead of locking work into fixed-length sprints, it visualizes work as it flows continuously through columns on a board — typically To Do, In Progress, and Done — with cards representing individual tasks moving left to right as they progress.

The distinctive rule in Kanban is the work-in-progress (WIP) limit: each "In Progress" column has a maximum number of cards allowed in it at once — say, no more than 3. If the column is full, nobody is allowed to pull in a new task, even if they are free; instead, they help finish something already in progress. This sounds restrictive, but it directly attacks a common team failure: starting many things at once and finishing few of them. A WIP limit forces the team to finish before starting, which in practice moves work through the system faster than letting everyone start whatever they like. Kanban suits teams with a steady stream of similar-sized requests — like a support or maintenance team fixing bugs as they arrive — better than Scrum's fixed-sprint commitment does, because there is no need to force a constant trickle of small, unpredictable tasks into rigid two-week boxes.

Common misconceptions, corrected

Misconception 1: "Agile means no planning." This is backwards. Agile teams plan constantly — just in small, frequent doses instead of one giant dose at the start. Sprint Planning happens before every single sprint. What Agile rejects is not planning itself, but the idea that you can plan the entire project in perfect detail before writing any code, and that the plan should never be revisited.

Misconception 2: "Agile and Scrum are the same thing." Agile is the underlying philosophy — the four values and twelve principles from the 2001 manifesto. Scrum is one specific framework built to practice that philosophy, with its own named roles, events, and artifacts. Kanban is another framework practicing the same philosophy, with a very different mechanism (continuous flow with WIP limits instead of fixed sprints). You can be "doing Scrum" without fully living the Agile values, and in principle a team could be highly Agile in spirit while using neither Scrum nor Kanban by name.

Misconception 3: "Since Agile welcomes change, a client can add anything to the current sprint at any time." Agile welcomes change between sprints, not mid-sprint chaos. Once Sprint Planning locks in the Sprint Backlog, the team is protected from new requests disrupting that sprint — new ideas go onto the Product Backlog and get prioritized for a future sprint. This time-boxed protection is precisely what lets a small, self-organizing team focus and actually finish things, rather than constantly context-switching.

Summary

• Waterfall builds software in one long sequence of phases and gets feedback only at the very end, which makes late-discovered problems expensive to fix.
• Agile breaks the same work into short, repeating cycles that each produce a small working increment, so feedback arrives constantly and cheaply.
• The Agile Manifesto (2001, Snowbird, Utah, 17 practitioners) states four values and twelve principles that prioritize people, working software, collaboration, and adaptability without discarding process, documentation, contracts, or plans entirely.
• Scrum is a concrete framework: fixed-length sprints, a ranked Product Backlog, a Sprint Backlog, Daily Scrums, a Sprint Review (inspect the product) and a separate Sprint Retrospective (inspect the process), and three roles — Product Owner, Scrum Master, Development Team.
• Requirements are written as user stories ("As a <user>, I want <goal>, so that <benefit>") with checkable acceptance criteria.
• Work is sized in story points on a widening scale (like 1, 2, 3, 5, 8, 13) to avoid false precision, and a team's velocity (average points completed per sprint) is used to forecast future sprints with simple arithmetic.
• A burndown chart tracks points remaining against days elapsed inside one sprint, comparing an ideal straight-line pace against the team's real, uneven progress.
• Kanban is an alternative Agile framework using a continuous-flow board with work-in-progress limits instead of fixed sprints.

Check your understanding

1. A team's Sprint Backlog is locked for the next two weeks when a stakeholder emails asking for an urgent new feature. According to Scrum practice, what should happen to that request, and why should it not simply be added to the current sprint?
2. Team Rihaan completed 24, 22, and 26 story points in its last three sprints. What is their velocity? If their remaining Product Backlog holds 216 story points, how many more sprints will it take, and how many weeks is that if each sprint is two weeks long?
3. Explain, in your own words, why Agile teams estimate difficulty using story points on a widening scale (1, 2, 3, 5, 8, 13) rather than estimating hours directly.
4. A Sprint Review and a Sprint Retrospective happen back-to-back at the end of the same sprint. What is the key difference between what each meeting is for, and who typically attends each one?
5. A support team fixes incoming bugs of unpredictable size and frequency, arriving at random times through the week. Would Scrum's fixed sprints or Kanban's continuous flow with WIP limits fit this team's work better? Justify your answer using what a WIP limit actually does.