September 6, 2026 · 7 min read
TL;DR: Continuous improvement questions test whether the loop closes. Recording a finding is the keyed answer when the knowledge would otherwise be lost, and a keyed wrong answer when the scenario needed something to change. Read the stem for which half is missing, then supply that half.
A team runs twelve retrospectives and fills a register with findings. Nothing about the way it works has changed since sprint two. On the exam, that project has failed at continuous improvement, and the register is the evidence.
Because they are two halves of one loop. The retrospective is the event that produces a finding; the lessons learned register is where the finding is stored so it survives the team. Scenarios test which half the situation is short of.
The measurement across this bank's 53 continuous improvement questions is unusually clean. Recording a lesson (in the register, the repository, the historical database, the organizational process assets) is the keyed correct answer in 13 of them and a keyed wrong answer in 15. Ten records have it on both sides at once: it is one of the four options, and whether it is right depends entirely on what the stem left undone.
| The stem shows | What is missing | Keyed answer |
|---|---|---|
| A finding reached, team about to disperse | Durability | Record it in the register, archive to process assets |
| A finding reached, work still to come | Action | Agree the change and apply it to the remaining work |
| Improvement sessions producing nothing new | Evidence | Bring measured data into the session |
| Retrospectives running but nothing changing | Ownership | Keep the cadence, fix the meeting: fewer items, named owners |
| One team's good result, four teams unchanged | Standardization | Put it into the standard method now, not the register |
Common trap: assuming "update the lessons learned register" is always safe. In one bank scenario, three of five workshop teams invented their own pre-shipment check and the one that measured every panel cut on-site rework from about 12% to 3%, with sixty more stores still to fit. Recording that result in the register is offered as an option and is keyed wrong. The keyed answer puts the check into the standard work instruction and audits adherence, because a gain sitting in one team's habit is not the project's until it defines how the work is done. The register preserves the finding without changing what anyone does next month. Every one of those distractors is explained, not just marked wrong, and the explanation names why the safe looking option loses.
Throughout the project, as findings emerge, not in one session at closure. Continuous capture lets the current project act on what it learned and keeps detail that memory erodes. Several bank scenarios key an end of project session as the wrong answer for exactly that reason.
One scenario has an agile team halfway through, having found that a message queue approach will not work and that user training every third sprint beats training every sprint. The keyed answer records both immediately. That training finding changes how the remaining iterations run, so holding it for a closure session throws away the benefit to the project that paid for the discovery.
A second scenario handles the practical objection. Team members say they have no time to update the repository because their other commitments have grown. The keyed answer makes lessons learned a standing item on meetings that already happen. Mandating a submission after every accepted deliverable adds the exact burden being complained about, and a consultant brought in to do it cannot capture what the team itself learned.
Closure is still where the register earns its keep. Archiving the plans, baselines, decision records and captured lessons into the organizational process assets is the step that becomes impossible once people have moved on and working repositories are cleared.
Evidence and a committed change. Sessions that run on recollection alone produce the same conclusions repeatedly, which is why seven of these questions key an answer that brings measurement into the room rather than more discussion.
Take a bookbinding works watching turnaround slide from six days to eleven. Its improvement session named four plausible causes and no way to choose between them, which is a measurement problem rather than an argument to be won. The keyed answer tracks cycle time and work in progress at each stage, because turnaround is mostly the time a job spends waiting, and that shows which queue is growing. An auction house in another stem has spent three cycles debating who writes condition reports. Its keyed answer runs a two cycle trial against a measure agreed up front, with the revert decision settled before anyone is invested in the outcome.
Then there is the team that wants to cancel retrospectives because they keep producing the same outcomes. The proposed remedy is wrong and the complaint is right. Keeping the cadence and fixing the meeting is keyed: pick one or two improvements, give each an owner and a slot in the next iteration's work, and open the next session by reviewing what happened to the last one. Halving the frequency removes half the evidence, since a retrospective is where a change tried last iteration gets assessed.
Sprint review is not the retrospective, and six of these questions turn on the distinction. The review is about the product, with stakeholders present, and adapts the backlog. The retrospective is about the way of working, the team alone, and produces a change to how they operate. Both happen at the end of every sprint. Whether the stand-up time suits everyone belongs in the retrospective; how to fix a specific regression does not, though why defects of that kind keep reaching the customer does.
There is no continuous improvement principle to memorize. Knowledge capture and reuse sit in the Governance performance domain, which owns the project knowledge process, and the improvement habit itself is carried by the Build an Empowered Culture principle. The July 2026 Exam Content Outline files the whole area under Business Environment, Task 6.
That move is why the topic reads differently now. Under the previous outline these questions were scattered across process artefacts. Grouping them as one business environment responsibility matches what they test: whether the organization is any better off afterwards, not whether you can run the ceremony.
Blameless framing belongs to the same standard. One scenario has a team member asking that a colleague's slow code reviews go into the lessons learned by name. The keyed answer records the process fact, review turnaround time, and drops the accusation. Keep the signal, and do not let a shared record become a performance file.
Retrospectives are tested from all three domains, incidentally: 40 records in Business Environment, 26 in Process, 25 in People. The concept follows you outside its home domain, and the reasoning holds wherever it turns up.
What is the difference between a retrospective and lessons learned? The retrospective is an event that produces a finding. The lessons learned register is the record that makes the finding outlive the team. The exam tests which one your scenario lacks.
When should lessons learned be captured on a project? Throughout, as they are identified. Saving them for a closure session forfeits the benefit to the project that paid for the learning and is keyed wrong in several bank scenarios.
Is a sprint review the same as a sprint retrospective? No. The review shows the product to stakeholders and adapts the backlog. The retrospective is the team examining its own way of working. Both run at the end of every sprint.
Where does continuous improvement sit in PMBOK 8? In the Governance performance domain, which owns the project knowledge process, with the habit under the Build an Empowered Culture principle. The 2026 outline files it as Business Environment, Task 6.
The 53 continuous improvement questions in PMP Practice sit inside a bank of 2,141 re-certified against PMBOK 8 and the July 2026 Exam Content Outline, and every wrong answer carries the reasoning that makes it wrong, explained rather than just marked. Start the free 20-question sample with no card and no signup.
Related: Knowledge transfer: tacit vs explicit · The closure sequence, in order · Business environment study guide
Sources: PMI — PMP Examination Content Outline, 2026 (PDF) · PMI — PMBOK Guide standards
What is the difference between a retrospective and lessons learned?
A retrospective is an event: the team inspects how it worked and commits to a change. Lessons learned is a record: the finding written into the register so it outlives the team. One produces the other. The exam mostly tests whether you know which one the scenario is missing, and 10 of the 53 continuous improvement questions in this bank put recording a lesson on both the correct and the incorrect side depending on that.
When should lessons learned be captured on a project?
Throughout, as they are identified, not saved up for the end. Capturing during the project lets the current project act on the finding and preserves detail that memory loses. Waiting for a closure session is a keyed wrong answer in several bank scenarios, because it forfeits the benefit to the project that paid for the learning.
Is a sprint review the same as a sprint retrospective?
No. The sprint review is about the product: the team demonstrates finished work to stakeholders and the backlog is adapted. The retrospective is about the way of working: the team alone examines the iteration and commits to an improvement. Different subject, different audience, both at the end of every sprint.
Where does continuous improvement sit in PMBOK 8?
There is no standalone continuous improvement principle. Knowledge capture and reuse live in the Governance performance domain, which owns the project knowledge process, and the improvement habit itself is carried by Build an Empowered Culture. In the July 2026 Exam Content Outline it is Business Environment, Task 6.