Kanban categorizes the work items in different classes of service. Classifying classes of service are typically defined based on business impact and cost of delay. This is a context specific activity that results in a specific set of service levels that are unique and differentiating to a line of business. Is there any alternative way to defining classes of service? Paul Boos, Software Leadership Coach at Santeon Group, describes alternative way in his recent blog on An Alternative for Identifying Classes of Service.
Paul says that there are some different kinds of work like maintenance and portfolio level items as part of kanban board for which he suggests a new way of finding classes of service. For maintenance activities like upgrades, defect/bug fixes, small to large enhancements, etc., team struggles to find ways of understanding the useful metrics for 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.
Paul mentions that there is some work items related to portfolio level. These items have different entry and exit criteria. So it’s worth to track them as separate class of service. He gives some examples as:
Reorganizing 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.
Paul categorizes 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. He suggests to place them on a grid as below:
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.
If you are 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.