What Is Scrumban Methodology? Scrumban Process Flow Explained
Welcome to the ultimate Scrumban guide. This article will talk about Scrum and Kanban in order to demonstrate the awesomeness of their hybrid PM system: Scrumban.
Just what is Scrumban methodology, in practical terms? We’ll define it below. Then we’ll look at various Scrumban characteristics and go over the essentials of Scrumban planning.
Scrumban overview: What is Scrumban Methodology? Our definition
The Scrumban definition usually begins by stating that it is a portmanteau of Scrum and Kanban. The Scrumban meaning in project management therefore is close to other agile project management definitions.
In short, Scrumban is a project management methodology that combines the time-planning of Scrum with the visual workflow management of Kanban.
So, what is Scrumban in agile?
When it comes to agile methodologies, Scrum and Kanban are popular choices.
Scrum is very common in software development. Kanban is more flexible and applied in many kinds of projects. You can read all about the differences in methodology and application in our Scrum vs Kanban comparison.
Before we go any further, let’s make sure we’ve defined our key terms.
So what is Scrum exactly? Scrum is a project management methodology intended to break a project down into smaller groups of tasks to be done over short periods of time. It’s about managing tasks and incrementally delivering products, or iterations of products. Meetings, also known as Scrum ceremonies, are held at key intervals to keep all stakeholders on the same page.
And what is Kanban all about? Kanban is a way of structuring workflows visually. A Kanban board is a series of columns, each representing a stage in your workflow. Usually the far left column is usually where your “to do” tasks sit. Tasks are made into cards, and as someone completes a stage of the task, it’s moved to the next column until it reaches the end of the workflow at the far right.
Scrumban, as covered above, unites the two methods. And the Scrumban meaning in agile PM clearly follows from the main principles of an agile approach, i.e. having a slightly open and flexible workflow and being super ready to adapt to changes. The Scrumban process overview takes the most agile elements from both Kanban and Scrum.
For example, Scrumban method takes the agile approach to workflows from Kanban, like the pull system where everyone grabs whichever task is ready without strict assignments. The method also takes the agile aspect of Scrum related to sprints, or short time bursts of work, which is more flexible than having fixed schedules and hard deadlines.
What is a Scrumban board?
So, what about the Scrumban board, what’s the deal with that? Well, you could say the Scrumban board begins where the Kanban board left off. It takes a lot of the basics from the Kanban board, and adds a few extra elements that make it an improved version of the more simple Kanban system.
First off, like the Kanban board, it is divided into columns. The three most important columns for any Kanban or Scrumban board are: to-do, in-progress, and completed. Of course, the middle column that shows the tasks in-progress can be further subdivided.
Let’s take the writing of an article as an example. In this case, the middle in-progress column can be divided into: pitch idea, review idea, write draft, review draft, edit draft, final review… and only then can the task of writing an article be moved to the completed column on the far-right.
Scrumban adds a few elements. First of these is called the work-in-progress limits, or the WIP limits. The idea here is that all the middle columns for tasks in-progress have maximum limits for how many tasks can be in the column simultaneously. The WIP limit will often be displayed on top of the column. So, if a project has a WIP limit of 5, that means that no more than 5 tasks should be worked on at the same time.
The next element of a Scrumban board is the on-demand planning element. Demand planning simply refers to a planning meeting that occurs every time the number of tasks to be done gets below a certain number.
In other words, if you have Scrumban with an on-demand planning number of 4, that means that as soon as the far-left to-do column’s tasks drop as workers take them on to 4 or less, a meeting will automatically be triggered. In this meeting, the team plans for the next stage of work and all the tasks that go with it.
Finally, there is month-bucket planning with Scrumban, which can be displayed on a Scrumban board in a variety of ways. The month bucket planning system divides future projects into 3 categories or buckets.
The 1-year bucket is for long-term goals, like inventing a new product.
The 6-month bucket is for when one of the ideas from the 1-year bucket begins to take shape, and the team might make a story for the product and begin thinking about high-level requirements.
The 3-month bucket is where you begin making a plan to execute the project, including figuring out tasks and resources.
Scrumban history: how & when was the Scrumban approach developed
The Scrumban methodology emerged from the conjoined histories of Kanban views with the structure of Scrum. The first official use of the term Scrumban was in 2008. In some essays by Corey Ladas about Kanban and lean methodologies, Ladas explains the benefits of Scrumban.
These are primarily the freedom from the strict time-boxed iterations and sprint planning of Scrum with the flexibility of the pull system from Kanban. Around the same time, the Certified Scrumban Practitioner came out, a guide that defines Scrumban elements like the rules and roles of Scrumban.
When to use Scrumban project management methodologies
You should use a Scrumban PM methodologies when:
You do not want to assign roles to your team
The team must have the freedom and flexibility to choose their own tasks
You want regular updates and verification stages
You need to produce iterations regularly
There is no hard deadline to your project
Scrumban advantages and disadvantages
Here are some Scrumban pros and cons:
The first benefit of Scrumban is that it’s agile, meaning it is great for adapting to changes and being ready to implement improvements through testing and feedback.
Scrumban gives freedom and flexibility to the project team, unlike Scrum.
In contrast to Kanban, Scrumban can prevent scope creep, bottlenecks or wasted downtime due to its work limits and on-demand planning.
Scrumban is great at producing deliverables through its iterative work process and short sprints of activity.
It is not expensive to implement Scrumban, as there are fewer professional roles or certifications.
As opposed to Scrum and other PM methodologies, there are fewer guidelines and rules for Scrumban.
As team members can choose their own tasks, this risks a pile-on for favorite tasks and neglect for other less-enjoyable ones. Managers can fix this with priorities, though.
A final drawback of Scrumban is that it is not the easiest project workflow system to monitor and manage at all the steps, and that stakeholders may not see the order going on inside the chaos.
Scrumban principles: what is taken from Scrum and Kanban to make the hybrid Scrumban model?
As any fusion methodology, Scrumban of course takes principles from Scrum and Kanban, some of which have been touched on before.
Perhaps let us begin with a few things that Scrumban rejected from Scrum. There are no roles in Scrumban like you have Scrum masters and product owners with Scrum. The Scrum team is basically like a team working with Kanban workflows.
When it comes to task delegation, Scrumban borrows from Kanban and not Scrum. This is the pull system, where each team member pulls a new task from the to-do column. Team members will get the freedom to choose new tasks based on their skill set or area of expertise, while project managers can encourage people to take certain tasks based on shifting priorities.
What Scrumban does take from Scrum is iteration planning and sprints. Now, the time-box constraints in Scrumban are not as strict as they are with regular Scrum. Still Scrumban benefits from this time-planning organizational structure of Scrum to help produce iterations in short bursts of work without being locked into long-term planning.
Scrumban can use the Scrum’s system of having daily meetings called stand-ups, whether it is a software development team or any other kind of work team.
Some more of the tools that Scrumban takes from Kanban are great visual representations of things like lead time, which tells you how long a task takes until it is completed. Another one is throughput amounts, which tell you how many work items and tasks got done during a specific period of time. Scrumban, like Kanban, is also excellent for spotting and dealing with work item bottlenecks which disrupt the flow of work.
With all the above in mind, here are some Scrumban principles which are derived from both Kanban and Scrum.
Organization means efficiency
Any project manager knows that being the grand organizer is one of their principal tasks. For this, a project manager must consider an organizational management approach to everything from creating the initial user stories and right down to the daily to-do list of tasks for the team members. This reduces wasted time and mistakes and improves the overall efficiency of the workflow. Organization as a principle applies to more than Scrumban but all agile frameworks.
Keep it simple
One of Scrumban’s tenets follows a 3-S principle: keep it simple, standardized and specialized. Making sure the project plan and instructions are always as simple as can be is crucial, as is each task breakdown. That is, if a task is too complicated, break it down to subtasks. Next, a team should use standardized language and Scrumban metrics across the board for greater efficiency. Finally, when applicable, Scrumban allows for people with special skills to pick and choose the tasks they’re best suited for.
Clearly lay out everything
Confusion and ambiguity are anathema to Scrumban. First of all, everyone should be aware of their specific roles and responsibilities, and this goes for all stakeholders and the Scrumban team. You should also be clear about the work policies, every item in the project backlog, and what the expectations are as laid out in the project charter regarding scope, timeframe, costs and quality.
Get your priorities in order
Task prioritization is so important with almost all project management methodologies. The reason having priorities is so crucial to Scrumban is because of the pull system where everyone is free to choose whatever tasks they please, so long as the manager has set down a level of priorities to guide the pull system. Priorities in Scrumban should be decided based on figuring out how much value to the project each task will bring.
The Scrumban process flow explained
If you want the process flow of Scrumban explained, then you’re in the right place. We’ll detail that below. Note that this process flow is not a rock-solid rule, and different project and product managers using Scrumban may differ.
With that caveat out of the way, here is the basic Scrumban process:
Beginning the project
This process begins with building your project team and creating a product backlog. Here, one will list all the functions the product promises to achieve and all the requirements needed for the project. New requirements, however, can still be added later, as this is an agile approach after all.
Planning the workflow
In this part of the process, the manager creates a schedule for the Scrumban sprints and decides which elements of the product backlog go in which sprint. You will also determine WIP limits and the on-demand planning trigger number.
Building the Scrumban board
Create the Scrumban board and all its columns. Apply the WIP limits to each column. Begin to populate the to-do column with all the tasks of the backlog. Make sure to mark the on-demand planning trigger number as well.
Taking the tasks
Now that Scrumban is built and ready to use, each project team member begins grabbing tasks from the to-do column and putting them in the in-progress column as they work to complete the task.
Minding the on-demand planning
When the number of work items in the to-do column drops below the trigger number of on-demand planning, the project manager should automatically call a planning meeting. Here, the team discusses what new tasks should be added to the project.
Minding your work limits
Likewise as above, the team needs to be mindful of the WIP limits as they take tasks out of to-do and into in-progress. If the in-progress column has its maximum number of tasks in it, then the focus should be on finishing tasks in-progress over starting new tasks.
Daily Scrum meetings, AKA stand-up meetings, should be done throughout the project lifecycle. Everyday, the people on the team state what they did yesterday, what they plan to do today, and what obstacles they foresee. You should also have retrospective meetings regularly after each cycle time per sprint has elapsed.
How to implement Scrumban
Above we talked about the Scrumban process flow, which is more about the life cycle of a project. Similarly, there are Scrumban steps to follow when implementing Scrumban. There is a bit of overlap in these two approaches, which is fine for reinforcement.
The six steps are:
Develop a Scrumban board
Set your WIP limits
Prioritize board items
Use planning-poker cards
Plan your meetings and stand-ups
1. Develop a Scrumban board
You could do this on a whiteboard with sticky notes, a bristle board with cue cards and thumb tacks, or even better, use a digital whiteboard as part of a project management software package.
2. Set your WIP limits
Whether for a single middle to-do column, or for a more complex board with several columns in between to-do and completed, there should always be limits to how many task cards or work items are in the middle columns. They should be clearly visually displayed.
3. Prioritize board items
Look at all the tasks piling up in the to-do column and attempt to put them in some sort of order based on their priority. This can be determined by things like task dependencies or the magnitude of value each completed task will add to the final project.
4. Use planning-poker cards
Planning-poker cards or similar methods are a great way to gauge everyone’s estimates and assumptions about things like how long a task should take. The idea here is for everyone to invisibly give their estimation, not influencing one another, and then use the results to determine durations.
5. Plan your meetings and stand-ups
Determine whether or not you will have daily stand-up meetings, and what time, and what everyone is expected to bring. You should also think about cycle times for iterations and larger retrospective meetings as well.
6. Continuous improvement
Scrumban, like most agile methodologies for product development, is all about working in short bursts, testing and evaluating that work, and then continually improving while on the go. Improvements can be made to your workflow process or to the end product.
Integrating Scrumban software into your workflow
To run projects in a more organized and streamlined manner, we recommend streamlining work with a project management tool.
Working with top-notch CRM project management software, you can apply Scrumban for in-office, distributed, and remote teams alike.
Common features include digital whiteboards for your Scrumban board, time tracking for lead time reporting, communications tools which are great for remote stand-up meetings, and more.
Key takeaways on the Scrumban framework
We hope this article has demystified the hybrid Scrumban framework. We’ve gone over the role in agile methodologies and outlined the practical workings of the Scrumban process flow, its principles, and given some tips on practical implementation. From here, it’ll be up to you on whether this framework reads as appropriate for your project needs.
But if you’re seeking freedom and flexibility, with regular updates for transparency and team synchronization, we think Scrumban is certainly a good option. Ditto for situations where you‘re seeking to iterate a product and don‘t have a hard deadline.
After all, when comparing Scrum to Kanban, why choose one when you can have the best of both with Scrumban?