Try 10 focused SAFe Agilist questions on Establishing Team and Technical Agility, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | SAFe Agilist |
| Topic area | Establishing Team and Technical Agility |
| Blueprint weight | 8% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Establishing Team and Technical Agility for SAFe Agilist. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 8% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Establishing Team and Technical Agility
Two teams on an ART frequently work for most of an iteration on long-lived branches and merge everything just before the System Demo. This often creates merge conflicts and failed builds that stall the Continuous Delivery Pipeline.
If they switch to smaller stories and integrate to the mainline at least daily, what is the most likely near-term impact?
Best answer: C
What this tests: Establishing Team and Technical Agility
Explanation: Integrating small batches frequently reduces the amount of code that must be reconciled at once and shortens feedback loops. That lowers merge risk, surfaces integration problems earlier, and prevents late-iteration build failures from stalling downstream testing and deployment. The immediate result is smoother flow through CI and the rest of the pipeline.
Small batch size and frequent integration are core technical practices for improving flow in a Continuous Delivery Pipeline. When teams wait to merge large, long-lived branches, the integration work accumulates, increasing the probability and severity of merge conflicts, broken builds, and hard-to-diagnose defects. Those issues create queues and rework that slow the entire pipeline.
With smaller stories and at-least-daily mainline integration, teams:
The key takeaway is that the primary near-term benefit is reduced integration pain and improved flow, not portfolio alignment or cost optimizations.
Small batches integrated frequently expose issues sooner, lowering merge risk and keeping work flowing through CI.
Topic: Establishing Team and Technical Agility
On an Agile Release Train, every code commit is merged to mainline and triggers automated build and test. When the pipeline succeeds, the system is automatically packaged and deployed to a production-like environment so it is always releasable, but moving the change to production requires a manual business approval.
Which DevOps practice is best described?
Best answer: C
What this tests: Establishing Team and Technical Agility
Explanation: This scenario describes continuous delivery because the pipeline can automatically build, test, and prepare a production-ready release at any time, yet a manual approval gates the actual production release. Continuous deployment would remove that manual release step. Continuous integration is only the earlier practice of frequently merging and validating changes.
Continuous integration (CI) focuses on frequently integrating code and validating each change with automated builds and tests. Continuous delivery extends CI by automating the path to a production-ready state so the system can be released on demand; the key distinction is that a manual business decision can still control when production release happens. Continuous deployment goes one step further by automatically deploying every successful change to production without that manual release approval.
In this scenario, the decisive factor is the manual production release gate: the ART is always releasable, but does not auto-release to production.
The solution is always in a deployable state, but production release still requires a manual decision.
Topic: Establishing Team and Technical Agility
An Agile Release Train is improving its Continuous Delivery Pipeline. Teams are moving to Continuous Integration (CI) with frequent merges and automated build-and-test runs on every commit.
Which practice is NOT aligned with effective CI in this context?
Best answer: C
What this tests: Establishing Team and Technical Agility
Explanation: Continuous Integration relies on integrating small changes frequently and verifying them with automated builds and tests. Practices that keep code integrated and validated reduce merge conflicts and uncover issues early. Delaying merges defeats this feedback loop and typically increases integration risk and rework.
Continuous Integration is the technical practice of merging to a shared mainline frequently and proving the system still works via automated builds and tests. In SAFe, CI supports fast feedback, higher quality, and reliable flow through the pipeline by detecting integration issues early and keeping work in small batches.
Effective CI practices commonly include:
Any approach that postpones integration until late in the iteration reintroduces “big-bang” integration, which increases merge conflicts and delays defect discovery.
CI depends on frequent merges; postponing integration increases divergence, conflicts, and late discovery of defects.
Topic: Establishing Team and Technical Agility
In SAFe, which statement best defines an enabler as a way to manage technical debt and improve flow and predictability?
Best answer: B
What this tests: Establishing Team and Technical Agility
Explanation: Technical debt slows flow and increases variability, making delivery less predictable. SAFe manages this by making necessary technical work visible and planned as enablers in the backlog and PI, so teams can reduce debt and create runway for upcoming features.
Technical debt creates rework, longer cycle times, and more defects, which reduces flow efficiency and makes forecasts unreliable. In SAFe, this is managed by capturing required technical work as enablers (e.g., refactoring, architecture improvements, test automation, infrastructure upgrades) and prioritizing them alongside features. Treating this work as first-class backlog items helps teams and ARTs intentionally pay down debt, improve Built-in Quality, and stabilize delivery by removing technical constraints that would otherwise cause unplanned work and missed commitments.
Enablers intentionally invest in technical work (e.g., refactoring, infrastructure, architecture) to remove impediments to flow and make delivery more predictable.
Topic: Establishing Team and Technical Agility
Midway through a PI, an Agile Release Train has completed several iterations and wants to confirm it is delivering value through integrated increments and potential releases. Which is the best evidence to validate that progress?
Best answer: B
What this tests: Establishing Team and Technical Agility
Explanation: The ART delivers value by integrating work across teams into a potentially releasable increment. The most direct validation is seeing integrated, working functionality demonstrated end-to-end in the System Demo and checking it against the PI Objectives. This provides objective evidence of outcomes, not just activity or utilization.
ART value delivery depends on frequent integration and objective validation that the solution increment works as a whole and supports intended outcomes. The System Demo is the primary cadence-based event where teams demonstrate integrated behavior of the system, making progress visible and enabling release decisions. When the demoed functionality can be traced to the PI Objectives (and their business value), it validates that the ART is producing integrated increments that are meaningful and potentially releasable, not just completing disconnected story work. Measures like ceremony completion, tool status, or utilization can be useful operational signals, but they don’t prove integrated value or customer-relevant outcomes.
Key takeaway: prioritize evidence from working, integrated solution increments over activity metrics.
A System Demo validates integrated, end-to-end value from multiple teams and shows releasable increments aligned to PI Objectives.
Topic: Establishing Team and Technical Agility
An ART repeatedly discovers critical vulnerabilities during a security review scheduled near the end of the PI, forcing rework and delaying release. What is the most DevSecOps-aligned correction?
Best answer: D
What this tests: Establishing Team and Technical Agility
Explanation: Late security reviews are a classic sign of large handoffs and delayed feedback. A DevSecOps-style correction is to shift security left by integrating automated security tests and policies into the CI/CD workflow and making them part of how teams complete work. This reduces queues, shortens feedback loops, and prevents vulnerabilities from accumulating until the end of the PI.
In a Continuous Delivery Pipeline, security needs to be built in, not inspected in late. When an ART finds vulnerabilities only at an end-of-PI review, it indicates delayed feedback and a handoff-based process. The DevSecOps correction is to integrate security into everyday development so issues are detected as code changes are made.
Practical actions include:
The key idea is reducing handoffs and automating checks so security becomes part of flow, not a late-stage event.
This shifts security left by building it into daily work with automated checks, reducing late handoffs and rework.
Topic: Establishing Team and Technical Agility
On an Agile Release Train, teams often work on long-lived feature branches and integrate only at the end of the iteration. System integration regularly takes several days and causes frequent merge conflicts and rework.
Which change best optimizes flow through the Continuous Delivery Pipeline by reducing merge risk while maintaining quality guardrails?
Best answer: B
What this tests: Establishing Team and Technical Agility
Explanation: Small batch size and frequent integration reduce the amount of divergent code that must be reconciled at once. That exposes conflicts sooner, lowers rework, and keeps work moving smoothly through build, test, and deploy with automation and quality checks. Trunk-based development directly supports this by encouraging continuous integration as the default behavior.
In a Continuous Delivery Pipeline, large batches and late integration create hidden queues: work “waits” in long-lived branches and then piles up during integration, where merge conflicts and rework slow flow. Using small batches with frequent integration (often enabled by trunk-based development and continuous integration) reduces merge risk because each change is smaller, has fewer dependencies, and is validated quickly with automated tests and code quality checks.
Practically, this means:
The key takeaway is to reduce the size and age of unintegrated work, not to add downstream “buffers” that hide problems and extend lead time.
Integrating small changes frequently surfaces conflicts early, shrinking merge work and reducing delays through the pipeline.
Topic: Establishing Team and Technical Agility
When optimizing flow through a Continuous Delivery Pipeline, how does SAFe define lead time?
Best answer: D
What this tests: Establishing Team and Technical Agility
Explanation: In SAFe flow metrics, lead time captures the customer/business waiting time from when a work item is requested until it is delivered. It is broader than cycle time because it includes time before work starts. It is not a rate-based measure like throughput.
SAFe uses flow metrics to understand and improve the end-to-end delivery of value. Lead time is the elapsed time from the moment work is requested (for example, when a feature is created or committed) until it is delivered to the customer or user. Cycle time is narrower: it starts when the team begins working on the item and ends when it is done. Throughput is different from both because it is a rate, measuring how many items are completed in a time period (for example, features per PI or stories per iteration). The key distinction is that lead time includes waiting before work starts, while cycle time does not.
Lead time measures how long it takes from when work is requested until it is delivered.
Topic: Establishing Team and Technical Agility
Mid-PI, a cross-functional Agile Team on an ART has 12 stories in progress across three features and two unplanned support requests. The team’s flow is deteriorating: many items are 70–90% done, cycle time is rising, and defects are showing up late in the iteration. The Product Owner says “we can just start a little on everything so nothing is blocked.”
What is the best next action?
Best answer: B
What this tests: Establishing Team and Technical Agility
Explanation: The team is overloaded by excessive work in process, evidenced by many nearly-done items, rising cycle time, and late defects. The best next action is to reduce concurrency by limiting WIP and swarming to finish a small set of the highest-value work. This improves flow, exposes issues earlier, and increases the chance of completing done, integrated value within the iteration.
In SAFe, too many concurrent initiatives create hidden queues: work sits partially done, feedback arrives late, and quality suffers. The symptoms in the scenario (many items nearly complete, rising cycle time, late defects) indicate WIP exceeds the team’s capacity. The best next action is to actively manage flow by limiting WIP and finishing work before starting more.
Practical steps:
Optimizing for utilization or expanding commitments typically increases delays and defect cost; completing fewer items to “Done” delivers more reliable value.
Reducing concurrency and finishing work restores flow, improves quality, and creates usable value faster than starting more items.
Topic: Establishing Team and Technical Agility
An ART has been struggling with large stories, long-lived branches, and painful end-of-iteration merges that delay the integrated build. The teams start slicing work into smaller changes and integrating to the mainline at least daily.
Which outcome is the best evidence that this change is reducing merge risk and improving flow through the pipeline?
Best answer: D
What this tests: Establishing Team and Technical Agility
Explanation: Small batch sizes and frequent integration reduce how far code diverges, which lowers the likelihood and impact of merge conflicts. The most direct validation is an outcome measure that shows less integration rework and smoother progression into a working, integrated build. Reduced time spent fixing merge conflicts indicates both lower merge risk and improved flow.
Small batches and frequent integration are Continuous Integration behaviors that keep changes close to the current code line, so conflicts surface early when they are smaller and easier to resolve. That reduces merge risk (fewer or less severe conflicts) and improves flow (less waiting and rework to get code into an integrated, potentially shippable state).
A strong validating indicator is an objective outcome measure tied to integration friction, such as reduced time spent on conflict resolution or fewer failed merges. These measures reflect whether teams are actually getting changes integrated smoothly, not just producing artifacts or adopting new practices.
Measures like planning readiness, new guidelines, or even higher test coverage can be helpful, but they don’t directly validate reduced merge risk and improved integration flow.
Less time lost to merge-conflict resolution indicates smaller, more frequent integrations are reducing branch divergence and keeping work flowing.
Use the SAFe Agilist Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the SAFe Agilist guide on PMExams.com, then return to PM Mastery for timed practice.