Corporate Coder

It's time for a little feedback on where we are for our Kanban system for Change Manaement.  For explanations of how and why we are implementing this sytem, please look at the posts, Using Kanban to manage your maintainence backlog post.  , and the More on Using Kanban to manage your maintainence backlog.  First good thing we get from Kanban is that it has given us good visibility into our Change Managent system.  For instance, we know how many tickets we have for each of our applications.  And we can track how long it's taking in each process (Backlog, WIP, Testing and Deployment).

One issue we have for our internal customers is how to limit the tickets that come in.  Since we aren't charging back, there is no real consequence to our customers for submittng change tickets, even if there is not a real ROI on it.  Our group is really the only gatekeeper on those changes. 

To give the business side some incentive to consider ROI, we're toying around with the idea of limiting the change requests for each application.  Perhaps by points.  For instance, let's say we have application widgetMaker!  We would say to our customers (in a customer meeting), you can have 20 points in the Backlog for widgetMaker.  We will work on those points and believe they can be done in 1 month (keep in mind the same group is working on other application changes).  Once that backlog is completed, we will come back to the stakeholders and replenish it with 20 more points worth of features.  And our group committs to communicate systematically the status of the tickets.

We are hoping to work on this, let's see how it work in Practice.  I haven't heard of anyone doing this without using some kind of cost to limit new features.  Monitor this space to see if this type of constraint can help deliver more useful features!

Eric