Agile and Scrum Explained for Software Engineering Students
Almost every software engineering module covers Agile and Scrum, and most group projects are supposed to follow them. Understanding them properly helps twice: in the exam, and in running a project team that actually delivers on time.
1. Waterfall vs Agile
The Waterfall model moves through fixed phases in order: requirements, design, implementation, testing, deployment. It works when requirements are clear and stable, but changes late in the project are expensive, and the customer sees working software only at the end.
Agile approaches deliver software in short cycles, getting feedback after each one and adapting. They suit projects where requirements are uncertain or likely to change, which describes most real software.
2. The Agile values
The Agile Manifesto (2001) values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
A common exam point: the items on the right still have value, the items on the left are just valued more.
3. Scrum roles
- Product Owner: owns the Product Backlog, decides priorities and maximises the value of the product.
- Scrum Master: helps the team follow Scrum, removes impediments and coaches; a servant-leader, not a manager.
- Developers: the people who build the increment each sprint. They are self-managing and decide how to do the work.
4. Scrum events
- Sprint: a fixed time-box of one month or less (often 1–4 weeks) in which a usable increment is created.
- Sprint Planning: the team decides what can be delivered in the sprint and how.
- Daily Scrum: a 15-minute daily meeting to inspect progress toward the Sprint Goal and adapt the plan.
- Sprint Review: the team shows what was built to stakeholders and gathers feedback.
- Sprint Retrospective: the team reflects on how it worked and picks improvements for the next sprint.
5. Scrum artifacts
- Product Backlog: the ordered list of everything that might be needed in the product.
- Sprint Backlog: the items chosen for this sprint plus the plan for delivering them.
- Increment: the working, usable result of the sprint that meets the Definition of Done.
6. User stories
Backlog items are often written as user stories: "As a student, I want to filter quizzes by module, so that I can find revision material faster." Each story should have acceptance criteria that say exactly when it is done, for example "the filter shows only quizzes for the selected module" and "clearing the filter shows all quizzes again".
A useful checklist for good stories is INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable.
7. Using Scrum in a student project
- Turn the assignment brief into a Product Backlog of user stories.
- Pick one-week or two-week sprints that fit your deadlines.
- Hold a short daily or every-other-day check-in on WhatsApp or in person: what did I do, what will I do, what's blocking me.
- At the end of each sprint, demo what works and agree what to improve.
- Keep a simple board (To Do, In Progress, Done) so everyone can see progress.
Teams that work this way usually find problems weeks earlier than teams that "start properly" a few days before the deadline.