In most Kanban systems established, classes of service refer to an assessment of impact to the business.  While I personally like this approach, often this assessment technique doesn’t fit well for some teams or organizational issues.  It may also not be very informative for some work items being managed.  I have always believed in using Kanban, and particularly its associated metrics, for identifying areas to improve.  Sometimes we need abilities to slice by similar items as far as impact, but that may have other degrees in which they vary. So I’d like to present a few other styles for identifying these.  I’ll start at a team level and move upwards towards something more organizational wide.

Maintenance Activities

I often seem to find teams performing maintenance activities (upgrades, defect/bug fixes, small to large enhancements, etc.) struggling to find ways of understanding the metrics that will be useful to them.  While an Expedite class of service, with its own identifiable swimlane and corresponding WIP limit, is invaluable, a standard class of service is not when the timeframe or scope tends to skew the metrics results.  I want to be able to predict when an activity may be done with some confidence.  If I lump all of the activities into one standard class of service, the larger items will skew the average lead time to a higher number than my smaller activities and my variability will be very high.

A concrete example is an ERP upgrade versus an important (but perhaps not critical enough to go into the Expedite column) bug fix.  The ERP upgrade may fix numerous (just as) important bugs as well.  Upgrades in ERPs often can’t be broken into apples to apples comparisons as the tasks are entirely different though the lifecycle that may be managed through the Kanban process may be identical.  Additionally, the items that must be completed for the definition of done (which become cumulative entry/exit criteria along my columns) may also be different.

BTW, these types of items may be tracked within a higher level Kanban and not necessarily a team based one…

Portfolio Items

Definitely moving a level or two upward, if I have portfolio items that need to follow an identical process, but may have varying entry/exit criteria or varying typical timelines may also be worth tracking as separate classes of service though each may be more or less equally important to the business (i.e. close to the same prioritization in the backlog).  Here’s some examples: reogranizing a particular function, redesigning a business process, implementing a new application (at the highest level).  Each may follow a similar process of: Backlog -> Analyze -> Implement -> Measure Performance -> Done.  The definition of done and timelines may be quite different on each of these items.  Wouldn’t it be nice the next reorganization being proposed I understood how long my last set took in terms of average lead time and its variability so I can predictably give an answer to the board?  I don’t want to skew my data with that for my last network upgrade.

One could argue that we could (or should) use separate Kanban boards for these, but I think this is less than useful. I can think of two reasons to have these on the same board.

1. I want to understand how my organizational WIP of change affects cycle-time overall.  This would be very difficult to do if these were spread across multiple boards. (This is not to say that each effort may not have its own more detailed board.)
2. Also if I want to also think through alternatives approaches and compare cycle-times as a magnitude of cost (since often time is money) and benefit (time to market), having these on the same board makes this much easier.  By tracking this information, I can use this information as input to my decision-making on which approach I may use.  For example, if I can use it as input to analyze whether I redesign my current business process or automate the existing process.  Knowing the cycle-time can become part of the analysis both in terms of cost and benefit

A Quick Analysis View

So how do we determine these different classes of service? Well I have already hinted at the dimensions that we will use.  We’re going to basically categorize the work item types by time it takes to get them done (just a gut feel of time) and differences in the scope of definition of done, looking for vastly large differences.  You can place these on a grid such as the one below.

So even items with a similar definition of done may have vastly different timelines, knowing this keeps us from skewing the data when we want like items.  Additionally, not lumping things that have vastly different definitions of done (column(s) exit criteria) yet follow an identical process at the level we are looking at it can also be very helpful.  The bottlenecks that may occur can be different; this also makes a useful distinction.  Lastly, I can now view all of these dissimilar items on the same board and yet have a means of distinguishing them and their corresponding metrics.

When one is stuck on identifying classes of service, or the classes of service between the items appears meaningless, give this a shot and see if it helps.  I’d be interested in other viewpoints.