Inspect and Adapt at the end of a Program Increment brings together three activities: a System Demo that shows the integrated solution to stakeholders, quantitative measurement that provides data on how the system is performing, and a Problem-Solving Workshop to address the largest gaps and root causes found. The sprint retrospective belongs to the team level and happens within each iteration to improve the team’s own process, not the ART-wide I&A agenda. So the item that is not part of the I&A three parts is the sprint retrospective. The other options align with I&A: the System Demo (often referred to as the PI/system demo), the quantitative measurements, and the problem-solving workshop.

This item tests how often the Team Demo happens within an Agile Release Train. In SAFe, teams on an ART work in fixed iterations, typically two weeks long. At the end of each iteration, the team holds a Team Demo to show the completed, integrated increment to stakeholders. This cadence keeps feedback fast and alignment across the train. Since the standard iteration length is two weeks, the Team Demo occurs every two weeks. While some organizations might refer to iterations as sprints, the key idea is the two-week rhythm, which is why every two weeks is the best fit.

In WSJF, the Cost of Delay components are tied to a common reference unit so you can compare items quickly and fairly. Starting each CoD component at a baseline of 1 anchors the scale, making the numbers purely relative rather than tied to absolute dollars or hours. When you rate components like business value, time criticality, and risk reduction, a score of 3 means three times the baseline value, and you get a simple sum for the CoD (for example, 3 + 2 + 1 = 6). This keeps the Cost of Delay a clear, interpretable relative measure that, when divided by the job size, yields a consistent, comparable WSJF value across backlog items. It also prevents zeros and keeps the math straightforward, which supports consistent decision-making.

Emergent design means the system’s architecture and design grow and adapt as work unfolds, rather than being fully specified before development begins. As teams implement features and learn what works, they make design decisions to fit current needs and continuously refactor to keep the design clean and scalable. This approach keeps the architecture flexible and responsive to changing requirements, with the architectural runway providing just enough guidance to support near-term work while allowing future evolution. The best expression of this idea is that teams grow the system design as user stories require. Upfront, fixed design contradicts agile practice, and having external consultants dictate architecture or repeatedly overhaul the design each sprint ignores team ownership and continuous learning.