Scrumban is a mix of Scrum and Kanban project management. Like both, it is meant for teams who need to embrace change; teams who acknowledge that plans and requirements change often, and it’s to their advantage to be flexible. Scrumban falls under the agile project management umbrella.

Even though Scrum was meant to be lightweight, many teams still find it too strict for their fast-paced agile environment. We advise teams to not fixate on whether they are following scrum strictly or not, instead to evolve their version of scrum to what works for them. Kanban on the other hand has been criticized to not be structured enough. Scrumban attempts to provide a middle ground between those two methodologies, by mixing some of the structure of Scrum with the loose planning of Kanban to create a methodology fit for agile teams.

Here’s what a simple Kanban board looks like:

Tasks move from the top to the bottom as they get done. You can add steps that are specific to your team’s needs. For example, you can split Doing into Development and QA. Kanban helps you visualize what there is to do and at the same time limits the amount of tasks you place under Doing.

The Scrumban process

Scrumban has short sprints (iterations) similar to scrum. This ensures that a team can easily assess, adapt and change their course of action quickly to changing environment. Planning and prioritization is done on demand or at the end of each sprint depending on what works for your team.

With Sandglaz, add a project, and set the Sprint length to what your team uses. This is where you will store, share and discuss all your tasks; where you will visualize what work needs to be done and who is working on what. To share it with your team, click on Share and add all your team members.

Sandglaz Scrumban

In the image above the Kanban rows are Dev, QA, and Completed. But, you can customize it as you wish by adding and removing rows. The columns represent the sprints. While the current sprint is split into Dev, QA, and Completed, future sprints are only split into Dev and QA, as completing a task will automatically move it to the current sprint saving the correct date of completion. You can always scroll back to view what was completed in past sprints too.

Scrumban scrolled back

Unlike Scrum, Scrumban doesn’t require any specific number of team members or team roles. The team members however are still self organizing in the sense that each team member chooses which task they are going to complete next. The planning meeting guides them into which tasks are more important. To grab a task they simple add their @username tag on the task. Teams can also filter on those tasks to see the tasks that belong to a specific team member.

scrumban-filtered

Hash tags work in a similar way and are meant to be used for categorization of tasks.

While you can place your tasks in the sprint you estimate you’ll get to it; you may also use the Someday column when you have no clue when you’ll get to the task. As your plans become clearer, you can easily drag and drop your tasks from the someday column to a sprint, and from a sprint to another as you see fit.

Scrumban-someday

As team members work on tasks, they can create subtasks, attach files, and discuss them with one another right from within Sandglaz

Scrumban-taskdetails

Scrumban teams often use the concept of feature freeze. It means when a deadline is approaching no more features can be added to the backlog.

Scrumban is a useful methodology to follow, and like any other, it’s important to remember that the point is not to follow the methodology, but to use it as a tool to reach your goals. So by all means adjust your process to suit your team and your goals.

Have you tried Scrumban yet? What were your experiences with it? Share with us in the comments below.