Choose the Best Workflow

After completing this unit, you’ll be able to:

Explain when you would use Scrum and when you would use Kanban to manage work.
Define interruption-driven work.
Explain why some teams use Scrumban.

At Salesforce, 70% of teams use Scrum and 20% use Kanban. The remaining teams use a mixture of both as they are compatible tools to use.

So how does your team decide which workflow is best to position it for success? Scrum or Kanban—or both? It really comes down to the type of work your team does, and how volatile or interruption-driven the work is. We can help you figure that out.

First, here are the main questions to ask yourself when considering which workflow to use.

Is your team focused on predictability and productivity for large projects?
How far in advance can your team plan?
Is the new work truly an emergency?
How quickly are you required to deliver the new work?

Is Your Team Focused on Predictability and Productivity for Large Projects?

Have a look at these two different types of work projects.

Scrum Case Study

Imagine if your team has to create a new website. The team can break down the work into the smaller projects. As the smaller work items are completed, the team can review their progress each sprint and adjust to ensure the whole project is delivered successfully. If the project needs a predictable delivery schedule, Scrum is the preferred workflow to use.

Kanban Case Study

Does your team have to deal with service outages? That’s an example of interruption-driven work. You can’t always know about or plan for outages 2 weeks in advance. Teams that work on architectural, service, or platform support tend to work on items that just pop up and create shifting priorities.

In this case, Kanban is the better process, as its flexible workflow allows for these kinds of unpredictable outages.

How Far in Advance Can the Team Plan?

You want to decide how much planning the team can complete and accomplish a project. Teams use Scrum when its backlog is filled with small chunks of larger projects that are easy to plan in advance.

Do your team’s priorities change often? Is it difficult to commit to scope of work for 2 weeks at a time? Does at least 25% of your work change mid-sprint? If your team is required to respond to new work items with very little notice, Kanban can work better for you. This is what we call interruption-driven work.

Is the New Work Truly an Emergency?

But what constitutes interruption-driven work?

Ideally, we want to limit changes for the team. There are a handful of things for teams to consider before classifying new work items as urgent or a priority.

Can this project cause disruptions that are time-consuming and demoralizing?
Do the disruptions prevent the team from finishing more valuable work?
Do the interruptions prevent the team from completing the most important thing first?

Kanban does not help a team if the work isn’t really interruption-driven. Here are some ways to determine if your work is or isn’t interruption-driven (and consequently, if Scrum is the better choice).

Ask yourself this: Is the needed work business-stopping or can we lose business if it’s not done now? Often, you can find that this isn’t the case, and these work items are needed urgently due to poor planning.
What’s the root cause of this needed work, and why wasn’t it identified in the planning phase?

Was it because we didn’t plan ahead?
Was it a new stakeholder or customer request?
Is the product not working?

If the urgent work is merely a result of bad planning, that is not interruption-driven enough to justify moving to Kanban.

How Quickly Do New Priority Work Items Have to Be Delivered?

High-priority interruptions are a fact of life at any competitive, successful company. What’s important is how those fire drills are managed.

So when an urgent request comes in, ask this: “How long can you or the stakeholder wait for an urgent item of work to be completed?” This is important to ask because Scrum and Kanban process projects on different timelines. If work is required as soon as possible, Kanban is the less disruptive workflow to use.

Remember: Scrum limits the capacity by focusing on a 2-week section of their backlog. Kanban limits the capacity based on preventing multitasking with work-in-progress limits.

Here’s a table that describes some of the key differences between the Scrum and Kanban workflow. Imagine a customer requests a new feature for the app we are building.

	Scrum	Kanban
Who prioritizes it?	Product owner prioritizes on product backlog	Product owner prioritizes on product backlog
Where does it go?	The product backlog is reordered for the next sprint.	The product backlog is continuously reordered for the next available person with capacity.
When does the work start?	During sprint planning, the team commits to the work in the next sprint.	As soon as there is capacity to work on it.
Why is there a delay?	Scrum focuses the team to deliver on their sprint commitments, and interruptions mid-sprint are discouraged.	Kanban focuses on efficient flow of work, so the top of the backlog is always the next thing to be worked on.
How long does it take to deliver?	It can be 2 weeks or more, depending on sprint status.	As soon as it is completed.

Use Kanban if it’s necessary to change directions often, minimize disruptions to a plan, and start the urgent work quickly.

Use Scrum if you’re managing a large planned project, your team can commit to a 2-week chunk of work, and the stakeholder can wait until the end of the sprint for the team to start the work.

You Can Use Both: Scrumban

Many teams at Salesforce benefit from using parts of both Scrum and Kanban to manage their workload. Often, teams like the structure of the regular planning and review cadence of Scrum, this allows them to manage progress easier. They also use the work-in-progress limits of Kanban to respond to urgent work while minimizing disruptions that Kanban provides.

During this trail, we’ve highlighted the common themes and ways people work, using the spirit of inspect and adapt to deliver the most value to our customers.