Free Scrum PSK-I Practice Exam with Questions & Answers

Lagging indicator metrics are metrics that provide information about past performance:

1.Velocity (Option A): This is a measure of the amount of work a Scrum Team completes in a Sprint. It is a lagging indicator because it reflects what has been done rather than predicting future performance.

2.Cycle Time (Option B): This metric measures the time taken to complete a work item from start to finish. It is a lagging indicator because it provides data on how long work items took to complete in the past.

3.Throughput (Option D): This refers to the number of work items completed in a given period. Like Velocity, it reflects past performance and is considered a lagging indicator.

Work in Progress (Option C) and Work Item Aging (Option E) are not lagging indicators:

•Work in Progress (C): is a current state metric that indicates how much work is currently in progress.

•Work Item Aging (E): is a leading indicator, providing insights into how long a work item has been in progress, helping predict delays or bottlenecks

Leading indicators are the most appropriate metrics for Daily Scrum because they provide information about the current state of the work and potential future issues. By tracking leading indicators, the team can identify potential problems early on and take proactive measures to address them.

Here are some examples of leading indicators that can be useful during Daily Scrum:

WIP Limits:Are the WIP limits being adhered to?

Blocked Tasks:Are there any tasks that are blocked or waiting for dependencies?

Task Progress:How much progress has been made on each task?

Team Mood:Is the team morale high or low?

By discussing these leading indicators during the Daily Scrum, the team can identify any impediments and take immediate action to keep the work flowing smoothly.

Lagging indicators, on the other hand, provide information about past performance and are not as useful for identifying and addressing current issues. Examples of lagging indicators include cycle time, lead time, and throughput. While these metrics are important for long-term analysis and improvement, they are not as actionable in the context of the Daily Scrum.

An SLE of 85% for 5 days signifies that the team anticipates they will complete items within 5 days, 85% of the time. This helps set clear expectations with stakeholders, ensuring transparency around potential delivery timelines. The SLE is based on historical data and provides a probability-based forecast, rather than a commitment. References: The Kanban Guide for Scrum Teams​.

1.The Kanban Board Provides Transparency (Option A):

A Kanban board visualizes the flow of work, making it easy for the Scrum Team to see the status of work items, identify bottlenecks, and inspect and adapt their processes. This visual transparency is a fundamental aspect of both Scrum and Kanban and supports the empirical process control central to Scrum(

2.Kanban Helps Achieve Faster, Healthier Flow (Option D):

By focusing on optimizing flow (e.g., reducing Cycle Time and managing Work in Progress), Kanban helps Scrum Teams achieve a faster, more predictable flow of work. This improvement in flow brings more rapid transparency, allowing for more effective inspection and adaptation during Scrum events such as the Daily Scrum, Sprint Review, and Sprint Retrospective(

Option B (Kanban metrics are used in the Sprint Review to allow the Product Owner to inspect Throughput and adapt the Scrum Team's Cycle Time) is not necessarily accurate, as the Sprint Review focuses on the product increment and stakeholder feedback, not directly on Kanban metrics.

Option C (Kanban helps Scrum Teams deal with simple and complicated work where empiricism is not necessary) is incorrect because both Kanban and Scrum rely on empiricism (transparency, inspection, and adaptation) to deal with work complexity

Cycle Time is a lagging indicator, meaning it can only be measured after a work item is complete. Therefore, it cannot be used as a leading indicator of the length of the feedback loop (Option A). Additionally, Cycle Time is not typically used during the Daily Scrum to help Developers inspect and adapt their Sprint; rather, it is more often used to assess overall process efficiency

The Service Level Expectation (SLE) provides the most benefit during the Daily Scrum. This is because the Daily Scrum is focused on inspecting the progress towards the Sprint Goal and adapting the plan to optimize the flow of work for the day. The SLE helps the Scrum Team understand if work items are on track to be completed within the expected time frames. If the actual cycle times are exceeding the SLE, the team can discuss and make adjustments during the Daily Scrum to address any impediments or to rebalance work, thereby maintaining a steady flow.

By using the SLE in the Daily Scrum, the team gets a daily, empirical measure of their workflow, allowing them to make quick decisions to keep work moving smoothly and predictably. This aligns well with the goal of the Daily Scrum, which is to ensure that the team is on track to achieve the Sprint Goal by the end of the Sprint(

Even when using Kanban, Scrum Teams still follow the Scrum framework, which mandates crafting a Sprint Goal during Sprint Planning. The Sprint Goal provides focus and alignment for the team, ensuring that all work contributes toward a common objective, rather than being taken on as needed. References: The Scrum Guide​.

An SLE combines a timeframe (elapsed days) and a probability, representing the likelihood that a work item will be completed within that timeframe. This helps to set realistic expectations for stakeholders and guide the team in maintaining a predictable flow. References: The Kanban Guide for Scrum Teams​.

When WIP limits are implemented, Developers are encouraged to focus on completing existing tasks rather than starting new ones. This leads to a more collaborative approach, as team members may swarm to complete items together. Additionally, limiting WIP enhances transparency in the process, which in turn strengthens self-management by the team. These principles align with Kanban’s emphasis on active management and the Scrum framework's focus on collaboration. References: The Kanban Guide for Scrum Teams​​.

Work in Progress (WIP) Limitscan be adjustedat any timeas needed to optimize flow and improve the system's efficiency. The decision to adjust WIP limits is typically informed by the team's observations of flow metrics (e.g., Cycle Time, Throughput, and Work Item Age) or to address bottlenecks or inefficiencies​​.

Supporting Reasons:

Kanban's Flexibility:

Unlike rigid frameworks, Kanban allows for flexibility in changing WIP limits whenever necessary to adapt to evolving conditions​.

Scrum Events:

Adjustments to WIP limits are often discussed during events like theSprint RetrospectiveorDaily Scrum, but these are not the only times changes can be made​​.

Empirical Process Control:

Teams use transparency, inspection, and adaptation to decide when to change WIP limits based on real-time needs​.

Why Not the Other Options?

B. When the Product Owner decides to change it:

Incorrect. WIP limits are a team decision and are not controlled solely by the Product Owner.

C. It never changes:

Incorrect. WIP limits are not static; they are dynamic and evolve based on team and system needs.

D. Only during the Sprint Retrospective:

Incorrect. While the Sprint Retrospective is a common time to discuss adjustments, changes are not restricted to this event.

E. Only during Sprint Planning:

Incorrect. Sprint Planning focuses on selecting work for the Sprint, not exclusively on adjusting WIP limits.

F. Only during the Daily Scrum:

Incorrect. Adjustments can be made during the Daily Scrum but are not limited to this event.

Adjusting WIP limits at any time ensures the team maintains an optimal flow, a core principle ofThe Kanban Guide for Scrum Teams​​.