ITIL4F ITIL Guiding Principles Practice Question
Which TWO of the following are examples of applying the 'Progress iteratively with feedback' principle?
⚠ Common exam trap
Many candidates confuse 'big bang' deployments (Option B) or annual releases (Option E) with iterative progress, failing to recognize that true iteration requires frequent, small increments with built-in feedback mechanisms.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Implementing a change in phases and gathering user feedback after each phase
Option A is correct because implementing a change in phases and gathering user feedback after each phase embodies the 'Progress iteratively with feedback' principle: work is broken into smaller increments, and feedback from each phase informs the next, reducing risk and enabling course correction. Option D is correct because two-week sprints with daily stand-ups and sprint reviews are a concrete agile implementation of iterative progress with continuous feedback loops, where each sprint delivers a usable increment and reviews capture stakeholder input. Option B is not correct because a big-bang rollout to all users at once is a waterfall-style, non-iterative approach that delays feedback until after full deployment. Option C is not correct because skipping testing removes the feedback and quality-control mechanisms that iterative delivery depends on. Option E is not correct because a single annual release with extensive testing is a long-cycle, non-iterative approach that provides no incremental feedback during the year.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implementing a change in phases and gathering user feedback after each phase
Why this is correct
This approach directly exemplifies the 'Progress iteratively with feedback' guiding principle. Implementing a change in smaller, manageable phases allows for focused development and deployment of increments. Crucially, gathering user feedback after each phase provides essential data and insights, enabling the team to learn, adapt, and refine subsequent phases based on real-world usage and stakeholder input, thereby reducing risk and improving value.
- ✗
Rolling out a new system to all users at once to avoid confusion
Why it's wrong here
Rolling out a new system to all users at once, commonly known as a 'big bang' approach, fundamentally contradicts the principle of progressing iteratively with feedback. This method defers all risk and learning to a single, large deployment event, providing no opportunity for early user feedback or course correction based on incremental releases. Any issues or misalignments are discovered only after full implementation, making them more costly and difficult to address.
- ✗
Skipping testing to speed up delivery
Why it's wrong here
Skipping testing to accelerate delivery is a detrimental practice that directly undermines the 'Progress iteratively with feedback' principle. Testing serves as a critical feedback mechanism, identifying defects, performance issues, and user experience problems before deployment. Eliminating this step removes a vital opportunity for learning and adjustment, increasing the likelihood of delivering a flawed product and necessitating costly rework, rather than continuous improvement.
- ✓
Using two-week sprints with daily stand-ups and sprint reviews
Why this is correct
Using two-week sprints with daily stand-ups and sprint reviews is a quintessential application of the 'Progress iteratively with feedback' principle, deeply rooted in Agile methodologies. Sprints define short, time-boxed iterations for delivering working increments. Daily stand-ups provide continuous internal feedback and coordination, while sprint reviews offer formal opportunities for stakeholders to inspect the increment and provide feedback, ensuring constant adaptation and alignment with value.
- ✗
Releasing a major update once a year after extensive testing
Why it's wrong here
Releasing a major update only once a year, even after extensive testing, represents a long development cycle that inherently delays the crucial feedback loop from actual user experience. While testing is important, an annual release schedule means that opportunities for learning and adaptation based on real-world usage are significantly postponed. This approach limits the ability to continuously refine and improve the service or product in response to evolving needs, contrasting sharply with iterative progress.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every ITIL4F question from scratch — 805 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ITIL4F practice question is part of Courseiva's free PeopleCert certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ITIL4F exam.