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 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.
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.Social tagging: Kanban > scrum > Scrumban