It's been a while since I've posted, but we've finally decided how we plan to implement this new Kanban System for our change tickets.  After talking it over we've decided to point our change tickets to show the level of effort.  Then we allow a certain number of points in the system.  We want to test going with a temporary team approach.  One or two developers working on the change tickets for a small length of time.  Then they cycle out back to standard projects and new devs work on the kanban system.  This way we don't have people dedicated to the team. 
Right now I am out in Seattle.  I met with Corey Lada (, and David Anderson ( and Corey showed a colleague and myself the Kanban systems they have in place.  I must say this has clarified my thinking in what we're doing.  Thanks for the assistance Corey and David! 
After seeing the actual board, I am rethinking using the points.  Instead of using points, we need to figure out a number of tickets that can be in the system.  For instance, we will always have 2 tickets in the system.  When the first ticket moves from Active to Testing, then Resolved, the next ticket goes up on the board.  Selecting the next ticket is the trick.  Currently we are thinking a FIFO system.  But at some point we will need to have some stakeholder intervention to approve the correct tickets.  But I'm not quite sure how our organization will handle that.  
Once we get this started we should be able to get some great metrics on Cycle Time.  I hope we can get some good software defect information as well.   I'll keep everyone posted.  In the meantime, if there are any questions, feel free to join the Kanban System David Anderson set up on yahoo (  Happy coding.