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.
How should I handle my Kanban board in this scenario where there are differently-sized tasks?.