Kanban

Kanban, as a process, has a lot of similarities to Scrum:

• The main unit of effort is a user story.
• Stories have the same sort of story-level process status, to the point where the same sort of task board, real or virtual, is used to track and provide visibility into work in progress.
• Stories should have all of their requirements and other relevant information ready and waiting before work on them commences. That implies that there is some sort of story grooming process, though it may not be as formally structured as the equivalent in Scrum.

Kanban, unlike Scrum:

• Is not time-boxed—there is no Sprint.
• Does not expect or require the daily status/stand-up meeting, though it's a useful enough tool and is thus commonly adopted. Other variants and approaches, perhaps focusing first on blocked items, then concerns on in-progress items, then anything else, are also viable.
• Does not expect or require that stories be sized, though again it's a useful enough tool and is not uncommon, especially if it is a useful criterion for prioritizing stories for development.

Kanban's primary focus might be described as an effort to minimize context changes, which plays out as working on single stories until they are complete before moving on to the next. This frequently results in prioritization of functionality by need, which lends itself well to situations where there are functional dependencies between stories.

Kanban's entire process is very simple:

• Stories (and their tasks) are made ready, and prioritized for work
• One or more developers selects a story, and works on it until it's complete, then repeats the process with another story, and another, and so on

• While development and work against current stories is underway, new stories are made ready and added to the stack of available work as details become available, and prioritized accordingly

Kanban, with different policies and procedures than Scrum, offers different advantages:

• Kanban is fairly well-suited to efforts where there are significant silos of knowledge or expertise, since it's focused on completion of functionality, no matter how long it might take
• Kanban handles stories and functionality that are both large and not easily divisible into smaller logical or functional chunk, without having to go through the process of subdividing them into Sprint-sized chunks (but see the next section for the drawbacks of this)
• Kanban limits Work In Progress directly, which reduces the likelihood of overworking developers, provided that the flow of the work is planned correctly and well
• Kanban allows the addition of new work by stakeholders at any point in time, and with any priority, though interruption of in-progress work is still best avoided
• Provided that each story is independent and deliverable, each completed story is ready for installation or implementation as soon as it's been accepted

It also has its own set of caveats:

• Kanban can be more prone to bottlenecks in development, particularly if there are large-scale or long-duration dependencies for subsequent stories—an example might be a data storage system that takes three weeks to complete—that is, there is a dependency for a number of small class structures that need it, which could be implemented in a few days if the data storage system were complete.
• Since it doesn't really provide any concrete milestones at a higher level than individual stories, Kanban requires more direct and conscious effort to establish those milestones if they are needed for external business reasons.
• More conscious thought and effort are typically needed for functionality that is being developed in phases in a Kanban process for it to be efficient—any functionality that has must-have, should-have, and nice-to-have capabilities that are all going to be implemented, for example, needs to provide some awareness of, and guidance future phase goals from the beginning to remain efficient.

• Kanban doesn't require that the team as a whole be aware of the design underlying the work, which can lead to misunderstandings, or even development efforts at cross-purposes. Making a conscious effort to de-silo design, and raise overall awareness of the larger-scale requirements may be needed, and it may not be apparent that it is needed at first.