Psk I Free Sample Questions

The primary purpose of tracking Work Item Age is to serve as a leading indicator of potential problems. When an item is aging and blocked, it signals a risk to the SLE. The Daily Scrum is the perfect event to inspect progress toward the Sprint Goal and adapt the plan. The most effective action is to make the problem visible and facilitate a team-based solution to unblock the item and restore its flow, rather than waiting for the SLE to be breached.

The Kanban Guide for Scrum Teams specifies that a Definition of Workflow must include, at a minimum: a definition of the individual units of value (work items), defined start and finish points, and one or more workflow states. The Scrum Master's name and WIP limits, while important, are not mandatory components of the Definition of Workflow itself.

The Kanban Guide for Scrum Teams specifies that a Definition of Workflow must include, at a minimum: a definition of the individual units of value (work items), defined start and finish points, and one or more workflow states. Explicit policies are a key part of defining how work moves through the defined states.

Kanban practices are complementary to the Scrum framework. A team can use a CFD to gain insights into flow, but it does not replace the Sprint Burndown chart. The Burndown chart tracks remaining work against time to help a team manage its progress toward the Sprint Goal, while a CFD visualizes work in different states over time, highlighting flow, WIP, and Cycle Time. Both can be used together to provide a more complete picture.

A wide distribution on a Cycle Time Scatterplot indicates high variability and low predictability. This is often caused by a combination of inconsistent work item size (some items are huge, some are tiny) and delays from external dependencies or blockers. These factors cause some items to flow quickly while others get stuck for long periods, creating the wide scatter. Addressing these issues by breaking down work more consistently and managing dependencies is key to improving predictability.

The most effective first step is to address the known bottleneck and the overall system load. Setting a WIP limit on 'Validation' (e.g., 2-3 items) makes the bottleneck's capacity explicit and prevents work from piling up. A second, broader WIP limit on the entire system (from start to near the end) encourages a pull system and prevents the team from starting too much work overall. This evolutionary approach respects the current process, makes the key problem visible, and starts the journey toward better flow without drastic, disruptive changes like eliminating Scrum.

Little's Law is a queuing theory formula that holds true for any stable system. For the law to provide meaningful insights in a Kanban context, the system's key characteristics (like average arrival rate and average departure rate) should be stable. This means the workflow isn't undergoing constant, radical change, and the averages for WIP and Throughput are calculated over a sufficiently long period to be representative of the system's typical performance.

By limiting WIP in the 'In Progress' columns, Developers will eventually reach a point where they cannot pull new work without an existing item moving forward. If items are waiting in 'Peer Review', the system signals that the most valuable action is to perform a review to free up WIP capacity. This creates a pull system, improving flow and fostering collaboration by encouraging team members to help where the work is needed most.

Throughput measures the number of work items finished per unit of time (e.g., per Sprint). By analyzing historical Throughput data (e.g., the team has completed between 8 and 12 items in each of the last 5 Sprints), the team can create a probabilistic forecast for the upcoming Sprint. While Cycle Time is used to forecast single items, Throughput is used to forecast how many items can be completed in a fixed time period.

Limiting Work in Progress (WIP) directly supports the Scrum value of Focus. By setting WIP limits, the team agrees to concentrate on a small number of items at a time. This reduces context switching, prevents individuals from being overloaded, and encourages the entire team to focus on finishing work before starting new work. This collective focus helps in delivering a valuable Increment each Sprint.

The start and finish points for measuring Cycle Time should align with the process the team wants to improve and forecast. Typically, this starts when the team commits to working on an item (pulling it from the backlog into an active state like 'Analysis' or 'Development') and ends when the item delivers value or is ready for delivery (e.g., after 'Testing'). The 'To Do' state is often a queue of options, not committed work, and 'Deployment' might be a separate process. The key is that the team explicitly defines these points.