Agile is a project management approach that breaks work into small, manageable chunks (often called "sprints"), with regular check-ins to review progress and adjust — rather than planning an entire project upfront and only reviewing it at the very end. This makes it easier to respond to changes and catch problems early. Scrum, a popular agile framework, uses short sprints, daily check-in meetings, and defined roles to organise a team's work.
Example
A software team building a new app might work in two-week sprints, each ending with a review of what was completed and a planning session for the next sprint — allowing them to adjust priorities based on feedback, rather than waiting six months to discover the whole plan needs to change.
Key terms
Agile:
A project management approach using small, iterative chunks of work with regular review.
Sprint:
A short, fixed period of focused work (often 1-4 weeks) in agile project management.
Scrum:
A popular agile framework using sprints, daily check-ins and defined roles.
Questions
1. Agile project management breaks work into:
Small, manageable chunks with regular check-ins
One single giant task with no breaks
Nothing; there is no structure at all
Random, unplanned actions
2. A sprint is:
A short, fixed period of focused work
An entire multi-year project
A type of software bug
A type of hardware
3. Scrum is:
A popular agile framework
A type of programming language
A type of hardware
A type of database
4. Agile approaches typically include:
Regular check-ins to review progress
No reviews at all, ever
Only one review at the very end of a multi-year project
No planning of any kind
5. A sprint in Scrum often lasts:
1-4 weeks
10 years
1 hour only
Forever, with no end
6. Agile is designed to help teams:
Respond to changes and catch problems early
Avoid all changes at any cost
Ignore feedback completely
Never review their own progress
7. A software team using two-week sprints reviews their work:
Every two weeks
Only once, after several years
Never
Once a decade
8. Why might agile project management be more adaptable than planning an entire project upfront with no reviews?
Regular check-ins allow adjustments based on new information or feedback throughout the project
Agile never allows any changes once a sprint begins
Planning everything upfront is always more adaptable
Adaptability has no connection to how often a team reviews progress
9. A daily check-in meeting in Scrum (a "stand-up") typically helps team members:
Share progress and identify blockers quickly
Avoid speaking to each other for as long as possible
Replace the need for any other communication ever
Have no connection to project progress at all
10. At the end of a sprint, a team typically:
Reviews what was completed and plans the next sprint
Immediately forgets everything that happened
Ends the entire project regardless of progress
Skips any form of review
11. Why might agile be well-suited to projects where requirements could change over time?
Regular reviews make it easier to adjust direction as new information emerges
Agile assumes requirements never change once set
Changing requirements always break an agile project entirely
Agile has no way to handle any change at all
12. A "product backlog" in agile project management generally refers to:
A prioritised list of tasks or features still to be completed
A type of software bug database only
A finished, completed project with nothing left to do
A type of hardware storage device
13. Collaborative development often relies on tools like shared code repositories mainly to:
Let team members work on and combine code changes together
Prevent any two people from ever working on the same project
Replace the need for any planning
Have no connection to teamwork at all
14. A "sprint planning" meeting at the start of a sprint is used to:
Decide which tasks the team will focus on during that sprint
Immediately end the entire project
Avoid any discussion of upcoming work
Replace the need for a product backlog
15. Why might breaking a large project into small sprints help reduce the risk of a project failing entirely?
Problems can be identified and addressed early, rather than discovered only at the very end
Small sprints always guarantee a project cannot fail
Breaking work into sprints has no effect on project risk
Problems are always hidden until the very end regardless of approach
16. Why might agile approaches be considered less suited to projects with completely fixed, unchangeable requirements from the very start?
Some of agile's core benefits (adapting based on feedback) matter less if nothing is expected to change
Agile is always the best approach for every single type of project with no exceptions
Fixed requirements always benefit most from an agile approach
Project requirements have no bearing on which project management approach fits best
17. Why might a "retrospective" meeting (reflecting on what went well and what didn't after a sprint) be a valuable agile practice?
It supports continuous improvement by learning from each cycle of work
Reflecting on past work is never useful for improving a team's process
Retrospectives always waste time with no benefit
Teams should never revisit or discuss how a sprint went
18. Why might clear, defined roles (like Scrum Master or Product Owner) help a team using agile methods work more effectively?
Clear responsibilities can reduce confusion about who makes which decisions or handles which tasks
Defined roles always slow a team down with no benefit
Roles and responsibilities have no impact on how effectively a team collaborates
Every team member should always do the exact same tasks with no distinction
19. Why might a team continuously prioritise and re-prioritise their backlog throughout a project, rather than fixing priorities once at the very start?
Priorities can shift as new information, feedback or constraints emerge during the project
Priorities should never change once a project begins
Re-prioritising backlogs has no real value in project management
A fixed, unchanging priority list is always the most effective approach
20. Why might collaborative development practices (like code review, where teammates check each other's work) improve overall project quality?
A second set of eyes can catch errors or suggest improvements an individual might miss
Code review always slows down a project with no quality benefit
Quality has no connection to how a team collaborates on code
Only the original author should ever review their own code
21. Why might a team choose shorter sprints (e.g. one week) over longer ones (e.g. two months) for a fast-changing project?
Shorter sprints allow more frequent opportunities to review, adjust and respond to change
Shorter sprints always mean less work gets reviewed overall
Sprint length has no connection to how quickly a team can adapt
Longer sprints always respond to change faster than shorter ones
Answer key (parent copy)
1. Small, manageable chunks with regular check-ins
2. A short, fixed period of focused work
3. A popular agile framework
4. Regular check-ins to review progress
5. 1-4 weeks
6. Respond to changes and catch problems early
7. Every two weeks
8. Regular check-ins allow adjustments based on new information or feedback throughout the project
9. Share progress and identify blockers quickly
10. Reviews what was completed and plans the next sprint
11. Regular reviews make it easier to adjust direction as new information emerges
12. A prioritised list of tasks or features still to be completed
13. Let team members work on and combine code changes together
14. Decide which tasks the team will focus on during that sprint
15. Problems can be identified and addressed early, rather than discovered only at the very end
16. Some of agile's core benefits (adapting based on feedback) matter less if nothing is expected to change
17. It supports continuous improvement by learning from each cycle of work
18. Clear responsibilities can reduce confusion about who makes which decisions or handles which tasks
19. Priorities can shift as new information, feedback or constraints emerge during the project
20. A second set of eyes can catch errors or suggest improvements an individual might miss
21. Shorter sprints allow more frequent opportunities to review, adjust and respond to change