Scrum and Kanban, there are many ways to get the best of both. Here is another way, following on from the previous example using tasks. Take note, this is not Kanban, but ScrumBan.

For whom ?

This approach is aimed at those of you who, having tried Scrum, have found the framework using sprints and the ceremonial too constraining for your context. In general, this context is a small team getting a fairly continual input flow. This input does not always need to be broken up into stories and tasks, as is the case with Scrum. The present technique can be used for a new project, or a new release, or even a new sprint for the current project.

Settings

With classic Scrum, the usual story development is as follows:

1. create a story in the sandbox
2. accept the story, it goes into the backlog
3. estimate the story
4. plan the story, it goes into the release plan
5. when planning the sprint, break the story up into tasks
6. finish the tasks in the sprint plan
7. declare the story as done (by PO)

This technique will let us skip steps 3, 5 and 7. To do this, some options must be modified in the project practices:

Rather than estimating the stories, we will simply count them. This also allows us to skip step 3.

The second option allows us to skip step 7. The last will create the story as soon as it is put in the sprint plan. This avoids having to create the task (step 5)

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.

Elements used

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 stories. We will use the Sprint Plan View as the column presentation is visually very useful. The tasks move through the columns. The task created by the “auto create task” option will temporarily represent our story.

Using the sandbox

The sandbox, where more interaction and discussion with the outside world is possible, is where user stories are collected. So once the stories have been put into the sandbox and after discussions with their creators, the Product Owner can accept them and they go into the backlog.

Using the backlog

Thanks to our options, stories put into the backlog are automatically given an estimation of one point. This is the same as counting them, and means they can be directly used in a sprint. Using a release plan is unnecessary with such an approach : we can immediately proceed with the sprint plan, and this puts the backlog in the left section.

Using the sprint plan

We can take a story from the minimised backlog in the left section and drag it onto the Sprint Plan, into the story column (the sprint being active). A task of the same name as the story will automatically be created and placed in the to do column. The story will next go to the in progress state. Other stories can be added, without limit. The task-story moves through the table, in the in progress column. When it is placed in the done column, the story is automatically declared done and moves underneath the stories in progress.

Blocked tasks can be clearly distinguished by colour (red). It’s easy to see if all team members have work, by filtering tasks by members. In the present version of iceScrum, there is no limit on the number of stories. However in the story column, as done stories go to the bottom, it’s easy to see how many stories are in progress, and so therefore they can be limited “manually”.

Indicators

With this approach, indicators for stories or features are of no use as they wouldn’t be updated till the end of the sprint. 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 story burnup chart showing two curves: one for the total number of stories and the other for those that are finished, updated daily. If there is always one task per story, the  task burnup chart is the same.

A bit of Scrum

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

• the Product Owner role
• the backlog (and sandbox in iceScrum)
• 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 urgent and recurring tasks to the sprint, as well as creating other tasks. This is indeed ScrumBan and not classic Scrum, in which, for example, it would be forbidden to add stories to a sprint-in-progress.

Possible future changes

We have seen how iceScrum can be used easily with a basic work-flow scenario. 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 sandbo
• estimation (1)
• in progress, with task ready
• in progress, with task in progress
• done (when task is done)

Another change would be to put a limit, for example on the number of tasks in progress for all stories. An essential yardstick in Kanban is cycle time; iceScrum already has tools to calculate it. When a storychanges state, its date is logged, as seen in the detailed view:

Dates for Accepted and Estimated are identical, similarly for Planned and In progress, this is due to our options. 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) and a done story can return to the in progress state. One option would be to add this possibility (to allow or prevent) to the practices settings.