Scrum in a nutshell:

• Split your organization into small, cross-functional, self-organizing teams.
• Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.
• Split time into short fixed-length iterations (usually 1–4 weeks), with potentially shippable code demonstrated after each iteration.
• Based on insights gained by inspecting the release after each iteration, optimize the release plan and update priorities in collaboration with the customer.
• Optimize the process by having a retrospective after each iteration.

Kanban in a nutshell:

• Visualize the workflow
• Split the work into pieces, write each item on a card, and put it on the wall.
• Visualize the workflow
• Use named columns to illustrate where each item is in the workflow.
• Limit Work In Progress (WIP): Assign explicit limits to how many items may be in progress at each workflow state.
• Measure the lead time (average time to complete one item, sometimes called “cycle time”), and optimize the process to make lead time as small and predictable as possible. Scrumban = Scrum + Kanban
• Use the prescriptive nature of Scrum to be Agile.
• Use the process improvement of Kanban to allow the team to continually improve its process

With the Kanban’s pull system in place, our flow will become smoother as our process capability improves. We can use our inter-process buffers and flow diagrams to show us our process weaknesses and opportunities for kaizen. As we get closer to level production, we will start to become less concerned with burndown and more concerned with cycle time, as one is the effect and the other is the cause. Average lead time and cycle time will become the primary focus of performance. If cycle time is under control and the team capacity is balanced against demand, then lead time will also be under control. If cycle time is under control, then burndowns are predictable and uninteresting.

Since the team now pulls work into a small, ready queue before pulling it into WIP, the team’s perspective of the iteration backlog’s utility is that it always contains something that is worth doing next. Therefore, we should use the least wasteful mechanism that will satisfy that simple condition.

A simple mechanism that fits the bill is a size limit for the iteration backlog. Rather than going through the trouble of estimating a scope of work for every iteration, just make the backlog a fixed size that will occasionally run to zero before the planning interval ends. That’s a simple calculation.

In Scrumban, we can do iteration planning at regular intervals, synchronized with review and retrospective, but the goal of planning is to fill the slots available – not fill all of the slots, and certainly not determine the number of slots. This greatly reduces the overhead and ceremony of iteration planning. Time spent batch-processing for iteration planning estimation can be replaced with a quality control inspection at the time that work is promoted to the ready queue. If a work item is ill-formed, then it gets bounced and repeat offenders get a root cause analysis.

Advantages

• Quality
• Just-in-time (decisions and facts just when they are needed)
• Short lead time
• Kaizen (continuous improvement)
• Minimizing waste (everything that is not adding value to the customer)
• Process improvement by adding some values of Scrum as and when needed