iceScrum was started a long time ago, long before there was any mention of Kanban in agile methodology. Scrum itself was still a recent term. When Grails migrated in 2010 we were already thinking about Kanban practices and how to gradually include them. With the present version of iceScrum, pure Kanban is not possible, but Scrumban, a mix of Scrum and Kanban, can be done. There are many ways to get the best of both (to use the title of the Scrumday address). Here is a description of one method with a Kanbas bias for work-flow management, suitable for small distributed teams or even for one person without a board for sticky notes. With this approach we will use a sub-set of the iceScrum features: the sprint plan (which we could rename to Kanban table) and the sandbox. We don’t use the backlog and hardly use the release plan.

Context

This technique can be used for a new project, or a new release, or even a new sprint for the current project. We use a small sub-set of iceScrum. The project practices options don’t need to be changed except for urgent tasks; these need to be displayed. The number of urgent tasks in progress must be limited. Initially, let’s use a value of 2…

Menu settings

As only certain views are used, let’s hide the others. This is done by dragging the buttons.

We will mainly be using the Sprint Plan view – we could almost use this exclusively – so let’s move it to the left.

Sprint ?

In a flow-oriented approach, sprints are not of great interest. With iceScrum, we are nevertheless going to create a sprint, but a very long one. The end-date can always be changed later on. The sprint can be created during project creation or later, with the release plan. It can also be done with the creation wizard or via the project practices, as shown below.

Element creation

In Scrum, as in iceScrum, stories are separate from tasks. One or more tasks go towards the making of a story. This is a useful distinction in project development, but is not needed for flow-oriented work. In our Scrumban approach we will be relying heavily on tasks, and with iceScrum in particular, urgent tasks. All our work will be in the form of urgent tasks for iceScrum. Urgent tasks can be created directly in the Sprint Plan view.

Using the sandbox

Another possibility, more adapted to information input from several different sources, is to create a story in the sandbox. Although we don’t want to use stories as such, the sandbox allows greater possibilities of contact and discussion with the outside world, and what is put in there is called, for historical reasons, a story. So once the stories have been put into the sandbox and after discussions with their creators, the Product Owner can accept them as…urgent tasks (this can only be done if the sprint is active).

Using the sprint plan

The sprint plan is reduced to a single line containing only urgent tasks and showing the previously defined limit. Created tasks are shown in the To do column . Once the sprint is active they can be moved to the In progress column. The fundamental principle of Kanban is limiting the work in progress. The limit defined in iceScrum prevents violating this principle: a task cannot be added to the To do column if this limit has been reached. If a task cannot terminate normally, it can be declared blocked and this will show up visually. In the same way (by using the block command), tasks that are unable to start can be visualized.

Using this approach, a time estimation in hours for individual tasks is usually unnecessary. However, with iceScrum, it is possible to indicate the remaining time for each task. As this table will be used for a long time (compared to a classic sprint in Scrum), finished tasks will build up in the right column. In order to improve visibility in the other columns, it is possible to hide finished tasks, as shown:

Indicators

With this approach, indicators for stories or features are of no use. Even if tasks are estimated in hours, the sprint burndown in hours will have no meaning, as in this context it will not necessarily decrease. The most useful indicator will be the task burnup chart showing two curves: one for the total number of tasks and the other for those that are finished, updated daily.

A bit of Scrum

With this Scrumban approach, we can still use some Scrum practices in iceScrum:

• the Product Owner role
• the definition of done as an indicator of using Kanban strategy
• the release, as milestone.

As an example, we can have a release of 3 months with a single sprint, thanks to our kanbanised sprint plan. It is of course still possible to add stories to the sprint in conjuction with this task-centered approach.

Future changes in iceScrum for an improved ScrumBan

We have seen how iceScrum can be used easily with a basic work-flow scenario. Some small changes could improve this use:

• add several rows to the table (the row for recurrent tasks could be used, but it has no associated limit)
• add a cumulated  flowchart to the sprint indicators, to be updated daily (the task burnup chart shows 2 states: done or not done, the sum of to do and in progress)

An obvious improvement to the Kanban approach would be to be able to modify the workflow. In the present approach, the workflow is fixed, with 4 states:

• waiting in the sandbox
• to do
• in progress
• done

To improve workflow dispay, at present through 2 views, an upcoming change in iceScrum will allow displaying the sandbox, as a thumbnail on the left (widget), simultaneously with the sprint plan. For these 4 states, the software automatically manages normal downstream flow (from left to right in the table), with the WIP limit only for the in progress state. An essential yardstick in Kanban is cycle time; as well as burnup, iceScrum already has tools to calculate it. When a task changes state, its date is logged:

For urgent tasks created outside of the sprint plan, it would only be necessary to add the date when they were added to the sandbox. Currently, the software allows upstream flow (from right to left in the table): a task in progress can be moved into the to do column (but a done task can not be undone). One option would be to add this possibility (to allow or prevent) to the practices settings.