Free PAL I practice test: 30 questions with answers

Transparency means the work and its progress must be visible to those responsible for the outcome, and here the Product Owner cannot see it. Inspection and adaptation depend on transparency, but the direct violation is of transparency. Predictability is not one of Scrum's three empirical pillars.

Openness means the team is candid about its work and its challenges, which early disclosure of impediments demonstrates. Respect concerns valuing each other's capabilities, Focus concerns concentrating on Sprint work, and Commitment concerns personally striving for the goals, so none of these fits as well.

The Sprint Goal is created during Sprint Planning as the single objective of the Sprint, and it explains to the Developers why they are building the Increment. A list of every backlog item belongs to the Sprint Backlog rather than the Sprint Goal, and the Sprint Goal is set by the whole Scrum Team, not by the Scrum Master alone.

The Scrum Guide describes one Scrum Team made of a Product Owner, a Scrum Master and Developers, with no sub-teams or hierarchies. Each of the other options creates sub-teams or splits accountability, which conflicts with that structure.

The Sprint Review is where the Scrum Team and stakeholders inspect the Increment and collaboratively adapt the Product Backlog. Individual performance is not appraised at the Review, Developers choose their own work rather than being assigned it, and the Definition of Done is not finalized there.

Only the Product Owner has the authority to cancel a Sprint, although they may consult the Scrum Team first. The Scrum Master, individual Developers and team votes cannot cancel the Sprint under Scrum.

A self-managing team decides internally how to deliver its work, so the manager should step back and coach rather than direct. The other options keep the manager or Product Owner in control of daily task and technical decisions, which is the very pattern that slowed the team.

The Scrum Guide says Scrum Teams are self-managing, meaning they internally decide who does what, when and how. The other options describe external direction, approval or assignment, which Scrum does not prescribe.

Silent individual writing before discussion gives quieter people an equal chance to contribute and is a standard facilitation technique. Silencing participants, taking over the summary, or replacing the group session with interviews each weakens the team's ownership of its retrospective.

A good facilitator stays neutral on content and uses questions so the group reaches and owns its conclusions. Pushing a preferred solution, rigidly fixing the agenda, or personally owning the summary all move decision-making away from the team.

Delegating suits people with high competence and high commitment, who can take decisions on their own in situational leadership. Telling and selling suit people who need more direction, and participating suits capable people whose commitment varies.

Servant leadership puts the team's needs and growth first, with the leader removing obstacles and supporting people. Command and control, transactional rewards and autocratic decisions all centre the leader's authority rather than the team's development.

Little's Law states that average cycle time equals work in progress divided by throughput, so 12 divided by 4 gives about 3 weeks in a stable flow. The other answers use subtraction, addition or an inverted division, none of which matches the law.

Probabilistic forecasts show a range of possible dates with confidence levels, which is honest about variability and easy to update as data arrives. Committing to the best case or the average hides the spread, and refusing to forecast leaves stakeholders with no planning information.

Probabilistic forecasts show ranges with confidence levels, and they should be updated as new throughput data arrives. A single fixed date hides uncertainty rather than removing it, and velocity-based dates are not always more reliable than throughput-based forecasts.

In agile product management, value is judged by the outcomes the product creates for customers and the organization. Counting features, story points or releases measures output, which can rise even when no value is created.

Customers purchase or fund the product, while users operate or consume it, and the two groups can differ, so a Product Owner must consider both. The other options reverse those roles or claim the two groups are always identical.

A burnup chart shows completed work and total scope separately over time, so growth in scope is visible next to progress. A burndown chart shows only remaining work, which can hide scope changes, while Gantt and pie charts do not show release scope trends.

Emergent architecture arises as the team builds and refactors small, tested increments, so design decisions are made and revised as evidence arrives. The other options describe up-front design, vendor-defined structure or the claim that no design decisions are needed.

Technical debt is the future cost created by choosing a faster, lower-quality path now, and skipped tests noted for later are a typical example. Scope creep, emergent design and continuous integration describe other practices or problems and do not capture a deliberate quality shortcut.

Only work that meets the Definition of Done counts as Done, so an item that skipped required security testing is not complete and returns to the Product Backlog. Counting it, releasing it untested, or approving the exception undermines the commitment to the Definition of Done.

Test-driven development writes a small automated test that fails first, adds only the code needed to pass it, and then refactors. The other options place testing after the code, shift design approval to the Product Owner, or rely on stakeholder sign-off, none of which is the TDD cycle.

Refactoring in small steps, with automated tests protecting behaviour, reduces duplication and risk without changing what the system does. Waiting until after release, rewriting everything, or copying the logic only increases the risk and debt the team faces.

Regular refactoring, automated tests in the Definition of Done and frequent automated integration all keep quality high as the product changes. Postponing all testing to a hardening phase and hiding known defects both increase technical debt and make the Increment less trustworthy.

Conway's Law observes that the design of a system tends to reflect the communication structure of the organization that produces it. The other statements make claims about system lifetime, team size or seniority that the law does not state.

Psychological safety is the belief that one can raise concerns or mistakes without punishment, and its absence stops problems being surfaced early. The other concepts describe code quality, scope growth and time use rather than the willingness to speak up.

Long-lived, cross-functional feature teams can deliver end-to-end customer outcomes with few handoffs, which is why agile organizations favour them. Layer-based component teams, handoffs between departments and disbanded project teams each add coordination steps or lose team learning.

Evidence-based management uses outcome data, such as customer satisfaction, to decide where to focus improvement rather than relying on output counts. Trusting velocity, raising capacity or waiting for an annual review all ignore the evidence that value is falling.

The four key value areas in Evidence-Based Management are Current Value, Unrealized Value, Time to Market and Ability to Innovate. Sprint burndown accuracy and developer utilization are output or internal efficiency measures rather than key value areas.

Westrum's pathological culture is power-oriented, so information is withheld and messengers are punished. Generative cultures share information freely, bureaucratic cultures are rule-oriented, and transformational culture is a leadership concept rather than a Westrum type.