Academy→Project Management→Scrum — Agile Project Framework
Scrum — Agile Project Framework
Scrum is an agile framework for developing and delivering complex products in short iterative cycles called sprints (typically 1–4 weeks). It defines three roles (Product Owner, Scrum Master, Development Team), five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), and three artefacts (Product Backlog, Sprint Backlog, Increment).
Why companies use it
- ·Delivers working product increments frequently, enabling early customer feedback and course correction
- ·Improves team transparency through daily standups, sprint reviews, and visible backlog management
- ·Reduces risk by time-boxing work — failed experiments fail fast and cheaply
- ·Widely adopted in software product development and increasingly in hardware engineering and R&D contexts
What hiring managers look for
- ·Scrum is the most common agile framework in engineering organisations — candidates without Scrum experience are increasingly rare and disadvantaged
- ·Hiring managers look for engineers who understand the purpose of each ceremony, not just who attend them
- ·Experience as a Scrum Master or Product Owner shows additional cross-functional leadership capability
- ·Understanding where Scrum works well (complex, uncertain work) and where it does not (repeatable operations) shows judgment
Typical interview questions
What are the three Scrum roles and what is each responsible for?
What is the difference between the Product Backlog and the Sprint Backlog?
What happens in a Sprint Retrospective and what makes one effective?
How does Scrum handle a situation where a sprint cannot be completed because requirements changed mid-sprint?
Have you worked in a Scrum team? What worked well and what would you improve?
Common mistakes
- ·Treating daily standups as status reports to management rather than synchronisation meetings within the team
- ·Allowing the Product Backlog to become a dumping ground — it must be regularly refined, prioritised, and estimated
- ·Not running Sprint Retrospectives, or running them superficially — this is the primary mechanism for team improvement
- ·Extending sprints when the team cannot complete the sprint goal — predictable sprint length is more important than completing every item
- ·Confusing Scrum with project management — Scrum does not replace a project plan; it delivers value iteratively within a project
Real engineering example
Related interview guides
Related topics
More in Project Management
Preparing for an interview?
Browse our role-specific interview guides written by engineers who know what hiring managers at ASML, NXP, and Philips look for.
Browse Interview Guides →