Scrum versus Kanban

SCRUM	vs.	KANBAN
Transparency is one of the 3 pillars of the Scrum empirical process control. However it is not explicit on how aspects of the work process is made visible.	VISUALISATION	This is a key tenant to Kanban where the work is made visible to everyone, which is typically displayed on a physical or virtual wall board.
At the start of a Sprint a selection of the work in Backlog is forecast to be done, thereby controlling the work in progress from the outset.	WORK IN PROGRESS	The workflow in a Kanban is controlled by setting a limit to the amount of work in progress (WIP) items in the system at any stage of the process.
Traditionally items in a Sprint have been tracked using ‘Velocity’ as a measure of progress. Story Points are a standard unit of measure.	METRICS	An item’s cycle time, lead time, age and throughput are key metrics to measure. Kanban does not use Velocity.
-Product Backlog -Sprint backlog -Increment The Scrum Guide gives examples: “Burn-up chart, burn-down chart, Cumulative Flow”.	ARTIFACTS	On the Kanban board for transparency display: -Cycle time scatterplot -Monte Carlo simulations -Cumulative Flow Diagram.
Work is contained within the Scrum Sprint, a time-box of one month or less.	TIME-BOX	There are no required time-boxes or iterations. While the Kanban method is iterative in nature, the continual improvement is expected to occur in an evolutionary fashion as work is continually completed.
An entire batch of Backlog items are pulled into the Sprint at once after being forecast to be done within the iteration.	PULL SYSTEM	Small batches of items are individually pulled in to the workflow when the team requires them based on available capacity.
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.	ROLES	There are no defined roles but two ‘optional’ distinct titled roles have emerged, Service Request Manager (SRM) and Service Delivery Manager (SDM).
Scrum Events consist of: -The Sprint -Daily Scrum -Sprint Planning -Sprint Review -Sprint Retrospective -Backlog Refinement	EVENTS & FEEDBACK LOOPS	Kanban has ‘feedback loops’ that consist of: -Daily Kanban -Delivery Planning Meeting -Replenishment Meeting -Service Delivery Review
At any time during or at least by the end of a Sprint a potentially releasable Increment of “Done” can be released.	RELEASES	At any time.
Before the start of every Sprint, the Product Owner is responsible for the selection of work to be done and orders in priority.	PRIORITISATION	The customer’s needs will determine the work to be done. Whilst work will be known in advance the Kanban system is more reactive to the changing item prioritises.
If the sprint goal is not going to be met then item(s) can be added or removed but only with the teams approval.	CHANGE	Items can be pulled in to the workflow at anytime to meet the customer needs.
Scrum is an iterative approach where a body of work is completed within a sprint(s) though a series of activities. Therefore the lifecycle is within this timeframe that results in a potentially releasable product Increment.	LIFECYCLE	Kanban does not have iterations but does limit work in progress that controls an item in the Kanban system. Therefore the lifecycle is based per item, captured through entering and exiting the system.
Deliverables are determined by sprints, or set periods of time in which a set of work must be completed and ready for review.	DATES	Products and processes are delivered continuously on an as-needed basis (with due dates determined by the business as needed).