Cycle Time is the amount of elapsed time from when an item is started to when it is finished.

The Scrum Team uses its SLE to find active flow issues and to inspect and adapt in cases when the SLE has not been met.

Though Scrum Teams can decide to make changes to their Definition of Workflow at any time, the recommendation is to do it as part of the Sprint Retrospective. The Definition of Workflow will have a material impact on how the Scrum Team performs. Restricting changes to the regular cadence provided by the Sprint Retrospective event will reduce complexity and improve focus, commitment and transparency.

The first action a Scrum Team should consider when their Cycle Times are too long is to lower their WIP.

Limiting Work in Progress can give teams a greater degree of self-management, focus, commitment and collaboration.

Work Item Age and Work in Progress are two of the four basic metrics that Scrum Teams with Kanban need to track. The other 2 that are missing from this list are Throughput and Cycle Time.

How items flow through the system are determined by pull-policies – these provide transparency on what has to happen so that a work item can be pulled from one workflow state to another. This can include items form the Scrum Team’s Definition of Done. Limiting Work in Progress creates a pull system, so policies that describe how Work in Progress is limited also contribute to how work flows.

The Developers are accountable for managing, executing and monitoring the plan for the Sprint. This plan is made transparent in the Sprint Backlog.

Cycle Time, Throughput and Work in Progress are key metrics for the Sprint Retrospective. Teams can also decide to take Work Item Age into a Retrospective, though this is not a key metric for this event.

As explained in the Kanban Guide for Scrum Teams, the minimum requirements for the visualisation of the workflow are; explicit policies about how work flows through each state, a definition of the work items, a definition of the workflow states that work items flow through from start to finish, policies for limiting Work in Progress, and defined points at which the Scrum Team considers work to have started and to have finished. 

The Scrum team can decide to change their WIP limits at any time, however because changes to the Definition of Workflow will have a material impact on how the Scrum Team performs, changes made during the regular cadence provided by the Sprint Retrospective event will reduce complexity and improve focus, commitment and transparency.

The primary effect of limiting WIP is that it creates a pull system. It is called a pull system because the team starts work (i.e. pulls) on an item only when it has the capacity to do so. When the WIP drops below the defined limit, that is a signal for the team to pull work.

Little’s Law only shows us that there is a relation between WIP, Cycle Time and Throughput. You should not use it to calculate your WIP limits.

The Scrum Framework is immutable, while implementing parts of Scrum is possible, the result is not Scrum. Dropping Scrum events results in lost opportunities for inspection and adaptation and reduces transparency.

Kanban is not a framework or a methodology. The Kanban Guide for Scrum teams describes Kanban as a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system.

With Professional Scrum with Kanban, Sprint Planning has more inputs and historical measures may make it easier to create a forecast.

Work Item Age and Work in Progress are both leading indicators and therefore key metrics for a Scrum Team to use in their Daily Scrum to help plan their work for the next 24 hours.

None of the above, though metrics such as Work Item Age can be helpful in Sprint Planning, the key metric to help the Scrum Team plan for the Sprint is Throughput.

Cycle Time and Throughput are the lagging indicators.