In the last post I shared some of the pains I have experienced with scrum. I’ve been reading up recently on kanban and scrumban in a bid to reduce some of those scrum pains. Here’s some changes that could address those pains …

Backlog

The product owner should still maintain a well ordered backlog - the item at the top should be the most important thing to do next. Super urgent stuff should go to the top of the backlog when it comes in.

Swim lanes

Items from the backlog should progress through the development life cycle through a kanban board consisting of the following lanes.

• grooming
• grooming done
• dev
• dev done
• testing
• testing done
• review
• release ready

Small bits of work

So, a feature should be taken from the backlog into the grooming lane where a member of the team will fully gather the requirements and design the solution. The solution could equate to a big chunk of work though and one of the things I like about scrum is that it encourages you to break bits of work up into small pieces. So, when the solution is designed, the work should be broken up into chunks of no greater than one days worth of effort. Those broken up chunks should then be put in the “grooming done” lane.

No planning

There will be no sprint planning. Developers should pull work from the top of the “grooming done” lane. Testers should pull work from the “dev done” lane.

Estimation

Estimation is done during grooming - we have already said that items should be no greater than one days worth of effort in the “grooming done” column. So, a time estimate could be done at this point.

WIP limit

A work in progress limit should be set on the “gromming”, “dev”, “testing” and “review” lanes. This should help throughput and lead times.

Daily stand up

I’m not sure about the daily stand up - the team should communicate ad-hoc as necessary to remove blocking issues and the kanban board should clearly show what is being worked on. The lead dev should still keep an eye on the overall flow of work and deal with any bottlenecks and as a result may call a team meeting but that meeting should be much more focused on the problem at hand.

Review

When a feature has been tested, it should be reviewed. A meeting could be organised once a week to go through the items in the review lane. Alternatively, videos could be recorded on each feature and shared with the stakeholders to drive feedback. The video approach may work better for distributed operations - e.g. when sales are out and about selling most of the time.

Release

A version should be released when there is just enough value in a release. When starting a new release cycle, the product owner should identify a check point in the “scoping done” lane where there is enough value.

Forecasts

So how do we predict when a release will be done? We have our check point in the “scoping done” column as the release marker. We have a time estimate on each item in the “scoping done” column. So, we can just total that time up to help forecast the release date.

100 days saving?

In the last post I said that a scrum team of 7 could spend 2 days on sprint planning in a sprint and a further 2 days in daily stand ups. Totalled up for a year is just over 100 days. This approach removes those planning and stand up sessions. So, will this approach really save 100 days of effort in a year?