Agile Software Development

Comparing Agile Methods: Scrum, Kanban, and Scrumban

It is always good to get a refresher now and then on the various methods that agile has at its disposal, especially if you want to experiment with fusing approaches. In a post at her blog, Elizabeth Harrin goes over scrum, kanban, and their independent offspring scrumban. Where do you stand in all of this?

Taking Sides

Scrum wants to set formal deadlines via time-boxed sprints in order to accomplish specified tasks. It likewise dictates formal roles with the product owner and scrum master, who set the vision and priorities and manage the scrum process respectively. It uses a product backlog to arrange and prioritize all the technical tasks that must be undertaken to complete a project. Typically, burndown charts are used to measure progress, which clearly show how much work has been completed at a given time and how much remains to be done. Essentially, scrum has its eye on the prize all the time.

Kanban is more loosey-goosey by comparison. There are no formal roles, and it generally does not have hard deadlines. On a kanban team, people simply take on more tasks to work as their time allows. There is no start and finish; there is only “go.” The great claim to fame of kanban is the kanban board, a visual representation of work in progress where tasks are placed into columns that indicate their current progress. And in order to measure progress with kanban, cumulative flow graphs and cycle time charts might be used.

Scrumban then is that non-committal punk rocker that plays by nobody’s rules but its own. Like in kanban, it does not demand specialized roles, and it uses a kanban board continuously for work. Cycle time charts also measure progress. However, scrumban combines continuous work “within longer planning cycles that tie in to your release dates.” As a result, scrumban teams do planning whenever their backlog is complete. Here is how it might work out:

Scrumban gives you the benefits of timeboxing work into sprints and releases with the flexibility of being able to add new work and cope with business-as-usual type work too. That would work well for smaller teams who manage project work alongside keeping the business operational, for example in a start up situation.

In practice, scrum is useful for time-sensitive major projects, whereas kanban is practical for regular operational work. There is a time and a place for all three methods, whether you lean left, right, or in the middle. You can view the original post here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.