Jump to content

Scrumban

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Jchyip (talk | contribs) at 00:53, 31 July 2015 (Capitalise proper noun). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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.[1]

History

With agile methodologies scrum and kanban starting to become noticed, some teams felt that neither fit their work process entirely - Scrum is too strict for a lot of fast-moving environments, while kanban is not structured enough. Scrum ban attempts to provide a middle ground between these two methodologies, mixing the structure of scrum and loose planning of kanban to create a methodology fit for fast changing environment.

The methodology

In scrum ban, the teamwork is organized in small iterations and monitored with the help of a visual board, similar to scrum and kanban boards. Planning meetings are held to determine what tasks to complete in the next iteration. The tasks are then added to the board and the team completes them, each team member working on one task at a time. To keep iterations short, task limits are added and a planning trigger is set in place for the team to know when to plan next. There are no predefined roles in scrum ban; the team keeps the roles they already have.[2]

List of practices

Iterations

Work iterations in scrum ban 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 by the number of tasks in that iteration and team velocity (the number of tasks the team can complete in a day). 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.[3]

On-demand planning

The planning in scrum ban 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 team velocity (how quickly they 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.

Prioritization

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

Bucket size planning brings the possibility of a long-term planning to scrum ban. It is based on the system of three buckets that the work items need to go through before making it on the scrum ban 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.[4]

The board

A simple kanban board

The basic scrum ban 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 scrum ban 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.[5]

WIP limits To ensure that the team is working effectively, scrum ban 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 scrum ban 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. WIP limit is usually equal to the number of people in the team, but could be expanded based on the team work specifics.

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

Scrum ban does not require any specific number of team members or team roles. The roles a team has prior to adopting scrum ban are kept when implementing scrum ban. They are reinforced by team members having to choose the tasks to complete themselves. The team roles in scrum ban are more specialized and less cross-functional [compared to?].

Pull principle

In scrum ban 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

Feature freeze is used in scrum ban 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.[6]

Triage

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.[7]

Terminology

  • Bucket size planning long-term planning approach in scrum ban, 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 need for new tasks on the board.

Tooling

Like other methodologies, scrum ban can be implemented with a help of various tools. The most basic scrum ban 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, possibility of attachments and discussions on tasks, time tracking, as well as integrations with other commonly used project management software.[8]

See also

References

  1. ^ "Scrum-ban".
  2. ^ Vasiliauskas, Vidas. "Scrumban - mixing agile and lean". Retrieved 22 December 2014.
  3. ^ Don, Wells. "Iterative Planning". Agile Process. Retrieved 14 January 2015.
  4. ^ Miseviciute, D. "Scrumban: on demand vs. long-term planning". Eylean Blog.
  5. ^ "Getting Started With Scrumban". About Scrumban. Retrieved 22 December 2014.
  6. ^ "Feature Freeze". OpenStack. OpenStack. Retrieved 14 January 2015.
  7. ^ "Software Triage". Sticky Minds. Retrieved 14 January 2015.
  8. ^ "Scrumban". Eylean Board. Retrieved 22 December 2014.