Archives for May2013

Scrum vs. Kanban vs. Scrumban: Team Members, Meetings, and Roles

We recently talked about the processes and the structure of agile methodologies, but at the center of the implementation of these methodologies is the team. Therefore, this time we review the differences of the three methodologies – Scrum, Kanban, and Scrumban – with respect to the team members, roles, and interactions.


In Scrum, there are several roles: Product Owner, Scrum Master, and the team itself.

Product owner is responsible for the product vision and priorities – and she is the person who decides which items or user stories are the most important to work on and complete in a sprint. The Scrum Master ensures that the Scrum process is going as agreed, removes any issues in the process and provides leadership with regards to the way it works. The team actually builds and implements the product.

Kanban and Scrumban do not have clearly defined roles for team members – so the roles may wary and it is up to the team whether any roles should be used at all.

Team members

Generally, Scrum is a methodology where the team members can be cross-functional. While there is no precise definition on what is cross-functional, the team as a whole should have the skills to complete the work within each iteration. As Scrum is time-limited methodology, it often happens that some team members need to work on several types of tasks in order to complete the work during the sprint – but as mentioned above, the methodology does not explicitly define what is cross-functional.

On the other hand, in Kanban the team members’ specialization or preference to tasks is preferred. Since the work is limited by work in progress, anyone with items in backlog can start working on another item as soon as they are finished with their own – which allows for specialization of the team members.

In Scrumban, the team can be either specialized or cross-functional.


The key difference in ownership is that while Scrum is a team-oriented methodology and is owned by a team, Kanban and Scrumban support multiple team ownership. So, for example in Kanban, different stages of the process can be owned by several teams – such as development team, quality assurance team, and others.


Several meetings are used in Scrum. They are sprint planning, daily scrum, and retrospective.

The sprint planning meeting involves pulling items from the backlog into the sprint and prioritizing the user stories that will be carried out during the sprint.

The daily scrum or stand-up meeting includes a short daily meeting where each member of the team briefly shares what they are working on. The daily scrum typically lasts no more than 15 minutes.

The retrospective reviews the teams progress after each sprint, and discusses ways to improve the process.

In Kanban and Scrumban, meetings are optional. They can be avoided entirely, or agreed upon on a regular or on demand basis.

Short Kaizen events can be done from time to time in order to focus. Kaizen events are defined as short, breakthrough events where employees from several departments or teams examine a problem, propose solutions and implement changes. These events can be used in Kanban and Scrumban from time to time, in order to solve issues or improve the process of work.

Continuous improvement

The approach to continuous improvement prescribes how the team makes changes and improves their work process based on the issues they encounter.

Scrum achieves continuous improvement by using a sprint retrospective meeting after the sprint, and discussing the outstanding issues as well as improvements to the way to work.

In Kanban and Scrumban, continuous improvement is optional. However, as mentioned above, short Kaizen events can be used for this purpose as well.

The next time we will be reviewing a few other differences between Scrum, Kanban, and Scrumban – including boards, rules, and who should use which methodology.

Read More

Scrum vs. Kanban vs. Scrumban: Planning, Estimation, and Performance Metrics

In the previous blog post we reviewed the basic differences of Scrum, Kanban and Scrumban. In this blog post we dwell deeper and look into how the tasks are planned in each of the methodologies, as well as how is the performance measured in Scrum, Kanban and Scrumban.

Planning routines 

Planning routines define how the work is planned during the process and when the planning sessions take place.

In Scrum, the product backlog items are pulled into to each sprint. Planning is regular and occurs in the beginning of each sprint.

Kanban, on the other hand, does not prescribe a precise planning routine. Therefore, the teams can choose to plan when they run out of backlog items (demand planning) or when the code or version is released (release / iteration planning). Scrumban, similarly to Kanban, uses planning when the backlog items are completed – and then plans for the new items.


Estimation is the process of determining the time required to finish each item.

In Scrum, the estimation of the time required for the items to be completed is typically done before the start of the sprint. Generally, the items have to be shorter than the time allocated for the time-boxed iteration. If they do not, they are usually split into smaller items.

In Kanban and Scrumban, estimation of the item duration is optional. After an item is complete, the team members simply pull the next item from the backlog and proceed with implementing it. Some teams still choose to carry out the estimation in order to have more predictability. Alternative approach to achieve predictability is to make sure that each of the items is of the same size, and therefore can be completed in the same amount of time.

New items in iteration

Agile methodologies also define how new items are added to the iteration.

In Scrum, it is forbidden to add new items during the sprint. Therefore, if there is a new item, it has to wait until the regular planning meeting in order to be included into the workflow. If the project requires dealing with incoming items (e.g. support), it is generally advised to use Kanban or waive this requirement in Scrum.

Kanban and Scrumban allow adding new items whenever there is enough capacity in the queue. Therefore, Kanban and Scrumban are very useful for functions with continuous flow of new items.

Performance metrics

The key performance metric in Scrum is the burndown chart. Burndown chart shows how much work within each iteration remains at each day or each hour of a sprint. A burndown chart example is provided below.

The blue line represents a typical burndown on an hourly basis, compared to the ideal burndown (the dotted line). The green line represents cumulative value that is added each hour. The key goal of the burndown diagram is to show whether the team is behind or ahead the schedule within each sprint.

In Kanban, the performance is measured via the cumulative flow diagrams and by estimating lead cycle time. Cumulative flow diagram shows the total items that are in progress, as well as the time it takes to complete them. Average lead cycle time estimation shows how much time, on average, does it take to complete one item. An example of the lead cycle time estimation is below. Similarly to Kanban, Scrumban also uses average lead time as its key metric.

It is important to note, however, that Scrum, Kanban, and Scrumban are just tools that are recommended and there is a variety of approaches of implementing the recommendations, depending on the team’s specifics. In the next blog post we will review the team requirements for Scrum, Kanban and Scrumban, including roles, meetings, ownership and continuous improvement.

Read More