What you'll learn
Quick Answer
Agile means working in short cycles, showing working software often, and adjusting rather than following a fixed plan. Scrum is one popular way of doing it: fixed-length sprints, a prioritised backlog, a short daily sync, and a review at the end.
The problem Agile responds to
The traditional approach was to gather every requirement, produce a full specification, build for months, then deliver. It is often called waterfall, and it fails in a specific way.
By the time software arrives a year later, the requirements have changed, and much of what was built is not what was needed. Worse, nobody discovers this until the end, when changing anything is most expensive.
Agile's response is to shorten the loop. Build a small piece, show it, get feedback, adjust, repeat. You are wrong just as often, but you find out in two weeks rather than twelve months.
That is genuinely the whole idea. Everything else is mechanism, and the mechanisms are frequently applied badly — which is why "Agile" has a mixed reputation among people who have experienced the ceremony without the underlying principle.
Scrum: the vocabulary
Scrum is the most common implementation, and it is what interview questions usually mean.
- Sprint — a fixed period, usually two weeks, in which an agreed set of work is completed. Its length does not change.
- Product backlog — everything that might be built, ordered by priority.
- Sprint backlog — the items pulled from the top of that list for this sprint.
- User story — a requirement written from the user's perspective: "As a student, I want to filter courses by semester, so that I can find mine faster."
- Standup — a short daily sync. What I did, what I am doing, what is blocking me. Fifteen minutes, standing, deliberately uncomfortable to keep it short.
- Sprint review — demonstrating working software at the end.
- Retrospective — the team discussing how the process itself went, and what to change.
Three roles: the product owner decides priority, the scrum master keeps the process working and removes blockers, and the development team builds.
The parts most often misunderstood
The standup is not a status report to a manager. Its purpose is for the team to coordinate and surface blockers. "I'm stuck on the auth token" is the most valuable sentence in it, and a standup where nobody ever says that has become theatre.
The retrospective is the actual engine of improvement, and it is the first thing teams drop. Without it, the same problems recur every sprint. It is also the ceremony students find most useful on a group project, because it creates a structured moment to say "we left integration until the last day again".
Story points are not hours. They express relative size — this is roughly twice that. The point is to avoid false precision, since developers estimate relative size far better than absolute duration. See time management for coding students on why estimates are unreliable.
Agile does not mean no planning. It means planning in shorter horizons with the expectation of change. "We're Agile so we don't write anything down" is a misuse, and a common one.
Using it on a college project
Most of Scrum is overhead for a team of three. Four pieces are worth taking:
- A prioritised backlog. One shared list, ordered. This alone prevents the common failure where everyone builds the interesting parts and nobody builds the boring necessary ones.
- Short cycles with something working at the end. A weekly target that runs. It forces integration to happen continuously rather than in a panic the night before.
- A quick sync, even twice a week. Mainly to surface blockers, since students stay stuck privately for days out of embarrassment.
- A retrospective after each milestone. Ten minutes. What worked, what did not, what we will change.
Use a simple board with To Do, In Progress and Done — GitHub Projects is free and sits beside your code. Limit how many items are In Progress at once; four half-finished features are worth less than one finished one.
How it comes up in interviews
Freshers are often asked "do you know Agile?" and answer by listing ceremonies. A better answer describes experience.
"On our final year project we worked in weekly cycles with a prioritised list. After the third week's retrospective we realised we were leaving integration to the end, so we started merging every two days, which caught a database schema mismatch early."
That demonstrates the principle rather than the vocabulary, and it is far more convincing than a definition.
Be ready for the distinction between Scrum and Kanban: Scrum works in fixed-length sprints with a committed scope; Kanban is continuous flow with limits on work in progress and no sprints. Support teams often prefer Kanban because work arrives unpredictably.
And you are allowed to be critical. "I've seen standups turn into status meetings" is a mature observation, not a red flag — provided you can also say what the ceremony is supposed to achieve.