Many Agile teams combine principles and practices from both Scrum and Kanban, evolving an approach that works best for their unique situation.
A key factor in the success of Scrum and Kanban is that development teams direct their own work, guided by business priorities. Members of both teams manage their own workloads. They establish their own rules for determining when a user story is ready to deliver to production.
Both Kanban and Scrum teams “pull” in work, rather than having management assign tasks to individuals. Scrum teams pull the highest priority user stories from the business product backlog, break each one down into small tasks, estimating the tasks and stopping when they’ve reached the amount of work to which they can commit for that time period.
Kanban teams determine how many user stories they can work on at any given time. They pull in stories until all their “work in process” (WIP) slots are full. Kanban teams plan, but they may choose to do it weekly, or when they’re running out of stories that are ready to pull in.
Both Scrum and Kanban leave the choice of development practices up to the development team. Core development practices including continuous integration, test-driven development and acceptance test-driven development or specification by example have been widely adopted, even by teams that don’t self-identify as “Agile.”
Perhaps the most obvious difference between Kanban and Scrum is in limiting work in process versus planning delivery in intervals of iterations. In practice, though, the differences tend to melt away. Though Scrum doesn’t call for formally limiting WIP, having several stories underway at the same time adds to the risk that no stories are finished by the end of the sprint. Let’s say you planned to deliver five stories. Having three finished and ready to release at the end of the sprint beats having five half-finished and nothing to deliver. Scrum teams must focus on finishing one story at a time, effectively limiting their WIP.
Scrum’s framework calls for estimating stories and tracking team velocity, the number of story points done each sprint, Kanban doesn’t prescribe estimating or using velocity. However, any Agile team needs some way to help the business plan when certain features might be delivered, knowing that plans always change.
Both Kanban and Scrum provide proven patterns and practices to help software teams deliver business value in a timely manner, allowing teams to work at a sustainable pace. Both provide ways for teams to use feedback frequently to try small experiments to address impediments and continually improve.