Kanban and feature size

Question

We are currently using Scrum within our organisation but are considering moving to Kanban (or Scrumban).

As part of our Scrum process we normally take into consideration size and complexity of features by assigning appropriate story points. I've briefly spoken to a few people doing Kanban and they say they don't do estimating meetings and sizing of features any longer. This must mean that all features must be of approximately the same size/complexity. In our environment, we have features which may require very little development/testing while others may be light on development but heavy on testing. For us, it doesn't necessarily work in all cases to set general queue sizes and limits. I think one of the reasons for this is that our development pipeline always have a mixture of new features (small and large), bug fixes and legacy system improvements etc. One idea I have is to continue estimating features with story points and introducing additional columns on the Kanban board to limit the number of medium and/or large features that can we worked on at a given time.

I found the following article about "standard-sized features" quite interesting. However, I don't think this approach suits us due to the problems I describe above.

http://blog.brodzinski.com/2011/05/kanban-standard-sized-features.html

How should I handle my Kanban board in this scenario where there are differently-sized tasks?.

Answer 1

You can get rid of the specific story sizing points and drop to a more basic level of S, M, L (T-Shirt sizes). Then, you can measure the throughput and cycle time (time needed to complete a feature) on each size, so over time you would learn that a "S" takes X days on average and a "M" takes X days and so on.

You will also learn about variability of size within different clusters of features, e.g. variability of size of big features is likely to be bigger than one of small features.

Note, that using T-shirt sizing instead of story point estimation should take you less time as it is more coarse-grained method. However basing on historical data (throughput and cycle time and variability) should improve quality of your estimates.

I wouldn't change your WIP limits in the columns though. The goal is to drive items through, not to allow the team to take on more just because they are all "S". Then you are just back to context switching. Note however, that especially big features would negatively affect the flow and cycle time.

Maybe from this, you start learning how to better get stories you are brining on, broken down in to pieces that are all "S" or "M" and decide the "L"s have to much variability in their throughput.

Answer 2

First, get some data to help make the decision.

I'd continue sizing stories as you do at the moment but start working in a pull based way rather than committing to a certain amount of points each sprint.

For a month or two, monitor both points completed per week and stories completed per week. Hopefully, you'll find that the ratio of stories to points per week is pretty consistent - this should give you the confidence to stop sizing and just track number of stories.

Another bit of data you'll want look at is story size distribution. Sample a few previous sprints. If you find most of your stories fall in range x to y but you occasionally get a much bigger (or smaller) story come in, you might want to consider approaches such as swim lanes or different coloured cards for large (or small) stories.

David Anderson's Kanban book has some good practical examples along these lines.

Answer 3

From my experience you should stay with the way you worked so far - I mean with story points. Too many changes at the beginning of the transition can make your movement to Kanban/Scrumban more difficult. I would recommend to find a Kanban Tool that supports story points.

Answer 4

Not introducing a ton of change at first is probably a good idea.

If by feature, you mean a large piece of work that will be broken down into smaller tasks, it's been recommended to me to estimate the number of tasks that feature would get broken down into. Once you have a guess at the number of tasks a feature will take, you can use your lead-time metric to estimate how long it will take to do that feature. I like that approach because you can do your 3-4 month-out estimation without having to go through all the work of breaking down the feature.

Regarding tasks being different sizes, I think you would be fine if your tasks were relatively close enough in size so that the law of averages would give you a reasonable lead-time metric. I would not recommend allowing large pieces of work to go into the queue for a variety of reasons. Instead, use the spidr techniques to break a story down.