Limit the Work in Progress
That’s the second of the core practices in the Kanban Method.
But is the Work in Progress really the only thing that should be limited?
Features in production can be unlimited – or shouldn’t they?
Lot’s of boards i have seen have unlimited “In Production” columns – or even feature an infinity sign (∞) above it.
Although I can relate to the Idea of having an infinite amount of room for features and capabilities that the world could use.
But then again there is a flip side to that coin…
When you have a product, you’ve got to support it!
In project work people – and yes, I have to admit, I’m one of them – tend to focus on the deadline – after all one definition of the term project is that it is a “… planned set of interrelated tasks to be executed over a fixed period …” (emphasis added), so naturally this fixed time scope has an impact on our decisions – as it should.
But when we think in terms of products this focus has to shift. We have to think beyond the delivery date. All of a sudden all those features are potential entry points for additional feature requests, bug reports, support demands, documentation demand and all other kinds of work-generation.
So at least on the portfolio level I think, it is a good idea to make sure that you don’t end up with too many things in production.
So, unless you’re doing it already, what do you think about putting a limit on the Features in Production?
till next time
P.S.: Of course the number of bug-fixes in production is only limited by the number of bugs we put in the system – and since we have the chance to put new bugs into it every time we change one tiny little thing, that column (bugs-fixed) really should have a ∞ on it…
Same goes for the typical UHD (user help desk) tickets – even if it has a certain charm to limit the number of times a user may call after he killed his system, that kind of limit doesn’t seem really feasible to me.
I’m really talking about product features at the portfolio level here.
And of course, as usual, YMMV