[vc_row][vc_column][vc_column_text]Scrumban is an Agile management methodology describing hybrids of Scrum and Kanban and was originally designed as a way to go from Scrum to Kanban. Today, Scrumban is a management framework that emerges when teams employ Scrum as their chosen way of working and use the Kanban method as a lens through which to view, understand and continuously improve how they work.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_text_separator title=”Scrumban vs Scrum”][vc_column_text]Scrumban is differs from Scrum since it emphasizes certain principles and practices that are substantially different from Scrum’s traditional foundation like:

• Recognizing the important role of organizational management (self-organization remains an objective, but within the context of specific boundaries);
• Allowing for specialized teams and functions;
• Applying explicit policies around ways of working;
• Applying the laws of flow and queuing theory;
• Deliberate economic prioritization.

[/vc_column_text][vc_text_separator title=”Scrumban vs Kanban”][vc_column_text]Scrumban is distinct from the Kanban method in that it:

• Prescribes an underlying software development process framework (Scrum) as its core;
• Is organized around teams;
• Recognizes the value of time-boxed iterations when appropriate;
• Formalizes continuous improvement techniques within specific ceremonies.

Perhaps most importantly, the principles and practices embedded within Scrumban are not unique to the software development process. They can be easily applied in many different contexts, providing a common language and shared experience across interrelated business functions. This, in turn, enhances the kind of organizational alignment that is an essential characteristic of success.[/vc_column_text][vc_text_separator title=”A Framework for Re-Evolution”][vc_column_text]When Scrumban was released, it was defined as a transition method for moving software development teams from Scrum to a “more evolved” software development framework. In actual practice, however, Scrumban has itself evolved to become a family of principles and practices that create complementary capabilities unique from both Scrum and the Kanban method. These capabilities have led to three distinct manifestations:

• As a framework that helps teams and organizations effectively adopt Scrum as a development methodology.
• As a framework that helps teams and organizations overcome a variety of common challenges scaling Scrum across the Enterprise.
• As a framework that helps teams and organizations develop their own set of Scrum-based processes and practices that work best for them—not to accommodate inadequacies and dysfunctions Scrum exposed, but to resolve them in a manner that was most effective for their unique environment.

[/vc_column_text][vc_text_separator title=”The Method”][vc_column_text]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 white board. In the case of decentralized teams, visual management software such as Assembla, Targetprocess, JIRA or Mingle are often used. 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 as 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.[/vc_column_text][vc_text_separator title=”Iterations”][vc_column_text]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. 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.[/vc_column_text][vc_text_separator title=”On-demand planning “][vc_column_text]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.[/vc_column_text][vc_text_separator title=”Prioritization”][vc_column_text]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.[/vc_column_text][vc_text_separator title=”Bucket size planning”][vc_column_text]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.[/vc_column_text][vc_text_separator title=”The board”][vc_column_text]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.[/vc_column_text][vc_text_separator title=”The team”][vc_column_text]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.[/vc_column_text][vc_text_separator title=”Pull principles “][vc_column_text]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.[/vc_column_text][vc_text_separator title=”Feature freeze “][vc_column_text]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.[/vc_column_text][vc_text_separator title=”Triage”][vc_column_text]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.

 

 

Source: https://en.wikipedia.org/wiki/Scrumban[/vc_column_text][/vc_column][/vc_row]