Scrumban- Stop Starting, Start Finishing

Scrumban is a hybrid Agile framework combined with Scrum and Kanban. It's a great transition step from Scrum to Kanban. A 2-week iteration with a pull-based system is recommended to minimise batching of work and making this model effective.

When to use Scrumban

1- Scrumban is a great solution for teams who need the structure of Scrum with the flexibility of a flow-based method, or for teams who are looking to transition from Scrum to Kanban.

2- To increase productivity. There is no overproduction. Products are manufactured only when they are needed.

3- Saving time: there is no need to do estimating or sprint planning.

How Does Scrum Ban Works:

1- Develop a Scrumban Board

2- Set Work in Progress limit

3- user stories Prioritisation

4- Estimate

5- Pull system and continuous workflow

6- Daily sync ups

7- Focus on cycle time than burndown

8- Make policies or clearer transition

Develop a Scrumban board-

Setting up the board with appropriate columns plays a vital role in successful execution. It is important to categorise all the phases which are involved in the software development life cycle so as to avoid crossing the WIP limit and putting the issues where they actually belong.

For example- Rather than just having columns for open, In progress, QA, and closed. It is a good idea to incorporate intermediary steps like In Analysis and PR Review.

Set Work in Progress limit-

To start with, the WIP across the board can be spread and have a maximum value of n-1, where n is the total number of team members. Set a realistic limit to keep your team from becoming overwhelmed and frustrated.

For example- If there are 8 team members, the WIP limit can be spread across the board with a total number of 7 or a maximum 8. PFB for reference.


It is recommended to prioritise user stories during the refinement and planning event. It gives the team members clarity of the business delivery and they are all on the same page. There is a specific story format but if all the stories are of similar size the throughput is consistent and helps in accurate future estimate predictions . Prioritisation on-demand – provides the team with the highest priority thing to work on next – no more or less.


We use the team's cycle time as a data point when writing stories for sprint planning. For example, say your team’s cycle time is 10 days or less at 85%. We would use this as a data point to make sure that the stories are sized such that it can go through your process to be “done” in 10 days or less.

Pull System and continuous workflow-

The pull system is a way to focus on getting the work done. Stop starting, start finishing. It is working for the board from right to left and focusing on that finishing part. User stories should only be pulled into the next column before ensuring that the WIP limit is not exceeded. In case, if pulling a user story might cross the WIP team, the team should work together and move the existing items to the next column and then move the new item.

Daily sync ups-

Good news travels fast and bad news travels faster. The standups are to make sure that the team is taking action on any stories that are stuck or not making progress. They should ask if stalled stories need pairing on collaboration or possibly need to be split into 2 or more stories. Connecting on a daily basis ensures that there is cohesiveness among team members.

Focus on Cycle time than Burndown charts

Cycle time is the amount of elapsed time that a work item spends as work in progress. It emphasises just-in-time analysis and planning (rather than batch-processing for iteration planning estimations)

Make policies for clearer transition

The policies help you have clarity on how to transition between columns. It ensures that everyone is on the same page and the policy is a single source of truth.

For example- We have defined criteria on when we can place the issue in a certain column.

The policies can also be around other processes like what to do when a team member is on leave.