From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Standards and Bodies of Knowledge

Scrumban is an Agile management methodology describing hybrids of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban.

Investigation of potential copyright issue

Please note this is about the text of this Wikipedia article; it should not be taken to reflect on the subject of this article.

Do not restore or edit the blanked content on this page until the issue is resolved by an administrator, copyright clerk or OTRS agent.

If you have just labeled this page as a potential copyright issue, please follow the instructions for filing at the bottom of the box.

The previous content of this page or section has been identified as posing a potential copyright issue, as a copy or modification of the text from the source(s) below, and is now listed on Wikipedia:Copyright problems (listing):

Unless the copyright status of the text on this page is clarified, the problematic text or the entire page may be deleted one week after the time of its listing.

Temporarily, the original posting is still accessible for viewing in the page history.

Can you help resolve this issue?
If you hold the copyright to this text, you can license it in a manner that allows its use on Wikipedia. Click "Show" to see how.
  1. You must permit the use of your material under the terms of the Creative Commons Attribution-Sharealike 3.0 Unported License (CC-BY-SA) and the GNU Free Documentation License (GFDL) (unversioned, with no invariant sections, front-cover texts, or back-cover texts).
  2. Explain your intent to license the content on this article's discussion page
  3. To confirm your permission, you can either display a notice to this effect at the site of original publication or send an e-mail from an address associated with the original publication to or a postal letter to the Wikimedia Foundation. These messages must explicitly permit use under CC-BY-SA and the GFDL. See Wikipedia:Donating copyrighted materials.
  4. Note that articles on Wikipedia must be written from a neutral point of view and must be verifiable in published third-party sources; consider whether, copyright issues aside, your text is appropriate for inclusion in Wikipedia.
You can demonstrate that this text is in the public domain, or is already under a license suitable for Wikipedia. Click "Show" to see how.
Explain this on this article's discussion page, with reference to evidence. Wikipedia:Public domain and Wikipedia:Compatibly licensed may assist in determining the status.
Otherwise, you may write a new article without copyright-infringing material. Click "Show" to read where and how.

Your rewrite should be placed on this page, where it will be available for an administrator or clerk to review it at the end of the listing period. Follow this link to create the temporary subpage.

  • Simply modifying copyrighted text is not sufficient to avoid copyright infringement—if the original copyright violation cannot be cleanly removed or the article reverted to a prior version, it is best to write the article from scratch. (See Wikipedia:Close paraphrasing.)
  • For license compliance, any content used from the original article must be properly attributed; if you use content from the original, please leave a note at the top of your rewrite saying as much. You may duplicate non-infringing text that you had contributed yourself.
  • It is always a good idea, if rewriting, to identify the point where the copyrighted content was imported to Wikipedia and to check to make sure that the contributor did not add content imported from other sources. When closing investigations, clerks and administrators may find other copyright problems than the one identified. If this material is in the proposed rewrite and cannot be easily removed, the rewrite may not be usable.
State that you have created a rewrite on this article's discussion page.
About importing text to Wikipedia
  • Posting copyrighted material without the express permission of the copyright holder is unlawful and against Wikipedia policy.
  • If you have express permission, this must be verified either by explicit release at the source or by e-mail or letter to the Wikimedia Foundation. See Wikipedia:Declaration of consent for all enquiries.
  • Policy requires that we block those who repeatedly post copyrighted material without express permission.
Instructions for filing

If you have tagged the article for investigation, please complete the following steps:

The Method[edit]

In Scrumban, the teamwork is organized in small iterations and monitored with the help of a visual board, similar to Scrum and kanban boards. To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard. In the case of decentralized teams, visual management software such as Assembla, Targetprocess, Eylean Board, JIRA, Mingle or Agilo for Trac are often used.[1] Planning meetings are held to determine what User Stories to complete in the next iteration. The User Stories are then added to the board and the team completes them, the team working on a few User Stories at a time as practical (the work-in-progress, or WIP, limit). To keep iterations short, WIP limits are thus used, and a planning trigger is set in place for the team to know when to plan next - when WIP falls below a predetermined level. There are no predefined roles in Scrumban; the team keeps the roles they already have.[5]


Work iterations in Scrumban are kept short. This ensures that a team can easily adapt and change their course of action to a quickly changing environment. The length of the iteration is measured in weeks. The ideal length of an iteration depends on the work process of each team, and it is recommended not to have iterations exceeding two weeks.[6] Velocity (a measure of productivity) is often used by the team to assess issues and trends in its throughput, in order to support continuous improvement.

On-demand planning[edit]

The planning in Scrumban is based on demand and occurs only when the planning trigger goes off. The planning trigger is associated with the number of tasks left in the "To Do" section of the board - when it goes down to a certain number, the planning event is held. The number of tasks that should trigger a planning event is not predefined. It depends on a team's velocity (how quickly it can finish the remaining tasks) and on the time required to plan the next iteration. The tasks planned for the next iteration are added to the "To Do" section of the board.


It is recommended to prioritize tasks during the planning event. This means the tasks are added to the board with marked priorities. It helps the team members to know which tasks should be completed first and which can be completed later. The prioritization can be done by adding numbers to the tasks or by adding an additional priority column, where the most important tasks are put at the top and the less important tasks below.

Bucket size planning[edit]

Bucket size planning.jpg

Bucket size planning brings the possibility of long-term planning to Scrumban. It is based on the system of three buckets that the work items need to go through before making it on the Scrumban board. The three buckets represent three different stages of the plan and are usually called 1-year, 6-month and 3-month buckets. The 1-year bucket is dedicated for long-term goals that the company has, like penetrating a new market, releasing new product, etc. When the company decides to move forward with a plan, it is moved to the 6-month bucket, where the main requirements of this plan are crystallized. When a company is ready to start implementing the plan, the requirements are moved into the 3-month bucket and divided into clear tasks to be completed by the project team. It is from this bucket that the team draws tasks during their on-demand planning meeting and starts working on the tasks.[7]

The board[edit]

A simple kanban board

The basic Scrumban board is composed out of three columns: To Do, Doing and Done. After the planning meeting, the tasks are added to the To Do column, when a team member is ready to work on a task, he/she moves it to the Doing column and when he/she completes it, he/she moves it to the Done column. The Scrumban board visually represents the progress of the team. The task board columns are adapted and expanded based on the team's work progress. The most common add-ons include priority columns in the To Do section and columns like Design, Manufacturing, Testing in the Doing section.

WIP limits -- To ensure that the team is working effectively, Scrumban methodology states that a team member should be working on no more than one task at a time. To make sure this rule is followed Scrumban uses WIP (work in progress) limit. This limit is visualized on top of the Doing section of the board (also could be on each column of that section) and means that only that number of tasks can be in the corresponding column at one time. A WIP limit usually is equal to the number of people in the team but could be expanded based on the specifics of the team's work.

To Do limits -- In order to have more productive planning meetings, the number of tasks in the To Do section can be limited as well. The same as with WIP limits, it is written at the top of the To Do section or on top of the corresponding columns and limits the number of tasks in the To Do section or specific columns.

The team[edit]

Scrumban does not require any specific number of team members or team roles. The roles a team has prior to adopting Scrumban are kept when implementing Scrumban. They are reinforced by team members having to choose the tasks to complete themselves. The team roles in Scrumban are more specialized and less cross-functional than what is expected in scrum teams.

Pull principle[edit]

In Scrumban tasks are not assigned to the team members by the team leader or project manager. Each team member chooses which task from the To Do section they are going to complete next. This guarantees a smooth process flow, where all the team members are equally busy at all times.

Feature freeze[edit]

Feature freeze is used in Scrumban when the project deadline is approaching. It means that only the features that the team already has for development can still be worked on and no additional features can be added.[8]


Triage usually happens right after feature freeze. With an approaching project deadline, the project manager decides which of the in-development features will be completed and which will stay unfinished. This guarantees that the team can focus on finishing important features before the project deadline and forget the less important ones.[9]


  • Bucket size planning long-term planning approach in Scrumban, which is based on moving the plans through a few steps.
  • Lead and cycle time the time that is taken from task creation or beginning work on a task to its completion.
  • On demand planning planning technique that is executed only when there is a need for new tasks on the board.


Like other methods, Scrumban can be implemented with a help of various tools. The most basic Scrumban implementation is a physical whiteboard with sticky notes. Electronic solutions, similar to scrum and kanban electronic boards are available as well. They offer a full automation of the board, where it only has to be updated by the team members. Electronic boards often also provide automatic reports, the possibility of attachments and discussions on tasks, time tracking, as well as integrations with other commonly used project management software.[10]

See also[edit]


  1. ^ a b Ladas, Corey. "Scrum-ban". Lean Software Engineering.
  2. ^ a b c d Reddy, Ajay. "Scrumban [R]Evolution- Get the most out of Agile, Scrum and Lean Kanban". Pearson.
  3. ^ Ladas, Corey (January 2009). Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press. ISBN 978-0578002149
  4. ^ Ladas, Corey (January 2009). Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press. ISBN 978-0578002149.
  5. ^ Vasiliauskas, Vidas. "Scrumban - mixing agile and lean". Retrieved 22 December 2014.
  6. ^ Don, Wells. "Iterative Planning". Agile Process. Retrieved 14 January 2015.
  7. ^ Miseviciute, D. "Scrumban: on demand vs. long-term planning". Eylean Blog.
  8. ^ "Feature Freeze". OpenStack. OpenStack. Retrieved 14 January 2015.
  9. ^ "Software Triage". Sticky Minds. Retrieved 14 January 2015.
  10. ^ "Scrumban". Eylean Board. Retrieved 22 December 2014.