Scrumban

Agile provides the development world with a range of useful and reliable methodologies. Though Scrum is one of the most used Agile frameworks, many companies and teams find it difficult to implement and choose Kanban for their software development processes.

Kanban vs Scrum is a battle that is well known in the Agile community. Many project teams all over the world tried to define the difference between Scrum and Kanban and often their efforts were ineffective. The logical solution that tends to be overlooked is Scrumban.

Both frameworks have their benefits and drawbacks, and, surprisingly, combining two approaches can be the best way to avoid possible development pitfalls.

If you are not familiar with working according to Scrumban or you’re not sure how to apply it correctly, then you’ve landed in the right place. This brief guide will help you get up to speed on what Scrumban is, find out its numerous advantages, discover how to put it into practice and how to measure success.

Since Scrumban is a hybrid framework, it will be useful to first have a good grasp of Scrum and Kanban. Let’s start with some basic info about two popular Agile models and then jump to everything you need to know about Scrumban.

What is Scrum?

Scrum is a widely known Agile framework that teams use to develop their products or services. The method consists of one to four-week sprints and is designed to help small self-organized teams deliver particular outcomes.

Scrum teams manage a list of overall project requirements (we know them as a backlog) and define collaboratively which ones will be accomplished in the next sprint.

After this, the sprint is “locked”. Any other work must be completed in a future iteration. Each sprint ends with a review of the outcomes. The plan for the next Scrum iteration is created or revised.

Scrum Pros

Scrum Cons

Improves scheduling. Allows tracking project workflow and receive intermediate results. Reduces the impact of errors. Errors that may be made in one Scrum can be reworked and repaired in the next Scrum. Improves communication and involvement. Allows introducing modifications quickly. Increases team productivity with the help of daily meetings. Helps to build better customer relationships.

Requires a highly experienced team. Stakeholders may often add more and more functionality. Can be time-consuming (after each sprint a new sprint planning is done, which may consume time in case of a longer sprint). Scope creep may become a real problem. Scrum is not ideal for large teams. Not the best option for micromanagers. It works best when the Scrum Master can rely on the team without being too controlling. Inexperienced team members can be a liability.

Now let’s recollect some common facts about the Kanban model.

What is Kanban?

Kanban is a visual development method applied to control and manage workflows. This representative of the Agile methods family uses boards (physical or digital) that show task-related cards to quickly oversee all outstanding work, work in progress, and completed work. Kanban team members update the status of their tasks by dragging them to the appropriate status column.

Kanban is less time-based than Scrum. Rather than focusing on sprints and scheduled deliveries, the model focuses on to-do lists and spreading work out across the team. Convenient Kanban boards assist teams in visualizing project workflows and understand what stage tasks are in.

Kanban Pros	Kanban Cons
Simplifies project management. Kanban boards provide visualization of the state of all work, enabling easier project management. There is no overproduction. Products are manufactured only when they are needed. Increases productivity. It helps to eliminate the time waste and people are able to focus on current work. Helps to make more informed decisions.	Lack of timing. Work continues until the items are complete. Inflexible in demand changes and product mix. Kanban boards must be up-to-date. Outdated ones can cause big problems. If too many items are tracked on a Kanban board, it can lead to confusion and make it difficult to accurately update information. Lack of deadlines.

After we recollected some essential facts about the two Agile methodologies, it’s time to come close to such questions as Scrumban vs Scrum and Scrumban vs Kanban. To do this, we need to delve into the concept of Scramban itself.

Introducing Scrumban

What is Scrumban methodology?

Scrumban is a hybrid Agile methodology that combines the set planned work from Scrum and the continuous improvement and task-focused work organization of the Kanban model. Sometimes you may face the definition “Kanplan.”

From Scrum to Kanban without pain

Scrumban was created to meet team needs in minimizing the batching of work and adopting a pull-based approach. The hybrid methodology provides software development teams with the flexibility to adapt to stakeholders and production requirements without overburdens.

Who invented Scrumban?

The answer can be found in the book “Scrumban: Essays on Kanban Systems for Lean Software Development” by Corey Ladas. The author described the method, claiming that Scrumban is aimed to transition a development team from Scrum to Lean/Kanban.

How does the hybrid approach combine the two frameworks?

The Agile hybrid method strives to find a middle ground for teams who find Kanban too flexible and Scrum too rigid.

What are the characteristics of Scrumban?

Scrumban utilizes the Scrum product backlog approach of planning, prioritizing, and allocating tasks. It also uses cozy Kanban boards to visualize the planned activities, allowing teams to see task progress and define bottlenecks. Some Scrumban teams use sprints, while others choose to abandon this requirement of Scrum.

The method often uses Kanban approaches around the amount of work that can be in progress at any one time. Using Scrumban software, a team can start a set amount of tasks at once.

When should we consider Scrumban?

• For maintenance projects (help desk and event-driven work);
• For projects with frequent and unexpected user stories (as well as projects with programming errors);
• For packaging phases;
• If Scrum is challenged by workflow issues, resources, and processes;
• If Sprint teams are focused on new product development;
• To manage improvement communities during/after Scrum roll-out.

What are the benefits of Scrumban?

• Scrumban saves time making processes more effective.
• Saved time allows focusing on quality control.
• It decreases waste and everything that is not adding value to customers.
• It provides continuous improvement.
• It leads to just-in-time actions. Decisions are made exactly when they are needed.
• Teams can improve processes by adding some Scrum values if needed.
• Scrumban boards have perfect visualization.
• It looks ideal for large-scale projects.
• It is really easy to adopt.
• Scrumban teams are usually more relaxed.

Scrumban Practices

1. Extended board

In Scrumban, the traditional Kanban board is divided into three columns: To do, Work in progress, and Done. The Work in progress column can be further split into more sections with new columns indicating the particular stage a task goes through. In this case, everybody knows the current situation, and tasks are completed as soon as possible. New tasks are put on the board without assigning them to a particular team member. For this reason, team members are able to choose which task they would like to work with.

2. Backlog limits

Scrumban allows preparing a list of tasks, putting them into the backlog, and setting the work in progress limit for the column. The team pulls items from the backlog into the process until it becomes empty. The empty backlog is a trigger that it is time to plan more tasks.

3. Prioritization

You may find tasks that you are not going to finish by the release time and move them to a future iteration. This is actually an important part of any process to deliver releases at a fixed time.
As a result, Scrumbun provides you with the following:

• Market-driven development. You can create new features that are demanded by the market rather than working on something you expect will make someone happy.
• Continuous delivery. Dividing the overall development process into small sprints, you are constantly delivering new software. This is good both for the product, as it becomes functional, and users, as they get the features they need. It’s also beneficial for the programming team. Programmers like writing code that works in production.
• More flexibility. Agile and Scrumban allow being flexible, to react to new events and requests from customers quickly, and see results and make amendments. This is actually one of the reasons why people select Agile in the opposition Agile vs Waterfall.

5 Steps to Understand How Scrumban Works

Scrumban is about implementing Kanban principles (workflow visualization and flexible processes) to the Scrum framework. However, Scrumban removed some rigid aspects of Scrum, allowing teams to create a custom approach to development.

Here’re some essential steps to develop Scrumban for your team:

1. Creating a Scrumban board

A board in Scrumban is similar to a regular Kanban board. It will be your main workflow tool, so add as many columns to your Scrumban board as your team requires to mark every discrete progress phase.

2. Establishing WIP limits

Scrum sets task and time limits for each sprint while Kanban focuses on continuous workflow. According to Scrumban, there is no need to set a limit on how much work your team can take on at any one point. That limit is the number of total cards on the board at any time. Trying to establish realistic limits will help your team to avoid becoming overwhelmed.

3. Ordering priorities

Following Scrum, you can assign tasks to specific people within your dev group for each sprint. Following Scrumban, your focus will be setting the priority order of all projects on the board. Your team will decide who will tackle certain tasks.

4. Forgetting about the Planning Poker cards

Scrum teams estimate how long each development task will take. That’s why they need such methods as Planning Poker to estimate the number of story points for each task. In Scrumban, work is continuous and not time-limited. Therefore, the team does not estimate story points. The key goal is to focus only on prioritizing the most important projects.

5. Appointing daily meetings

Besides the typical Scrum framework meetings (Sprint Planning, Sprint Reviews, and Retrospective meeting), you’ll also need Scrumban meetings that can include short standups for discussing the team’s plans and challenges for the upcoming day.

Scrum vs Scrumban

Kanban vs Scrumban

Choosing the Best Environment for Introducing Scrumban

Scrumban does not suit every environment or culture.

• You may want to stick to Scrum if your company has many experienced members, a clear understanding of user stories, customers who want to participate in the development process, and your corporate culture values timelines.
• You may want to stick to Kanban if your organization operates in a maintenance environment where new development is a small part of the team’s activities, pulling tasks as needed is important, and there are no projects defined for specific clients.

Consider Scrumban if:

• There are many unexpected changes to user stories and reworking of priorities in your project.
• Scrum practices have been unsuccessful due to a number of issues.
• You want to add pull features to the Scrum development.
• The rigidness of Scrum limits your team’s ability to adapt to change.
• The work is event-driven.
• The team is totally focused on adding features and supporting an existing product.
• You are interested in some principles of Kanban while working with Scrum.

Conclusion

The final thought about the Scrumban methodology is always going to be how the team responds to it.

This hybrid model combines the best of both Agile approaches to carry out projects. The key benefit of Scrumban is the fluidity of the method. After all, as is the case with any development methodology, organization and team buy-in will determine success.

Rather than partially apply one of the approaches, it is better to apply tools that are shared by the whole project team and try to use available Scrumban templates.