Classes of Service and Policies

David Anderson writes

Traditional project management treats every item homogeneously. Kanban allows us to break the triple constraint and optimize delivery based on risk. A Kanban card can have a class of service, an indicator that speaks to the risk associated with that feature.

For each item we can control its priority and speed of flow via pull-based prioritisation decisions made according to the Cost of Delay.

Classifying classes of service are are typically defined based on business impact, they will be a context specific activity that will result is a specific set of service levels that are unique and differentiating to a line of business. Some business may choose to delineate several classes of service based on the cost of delay, up to 3 classifications could be quite reasonable depending on the funds put at risk through delay.

Classes of service will be unique in your project, however here are some examples:

  • Expedite (or “Silver Bullet”)
  • Does the feature need to be delivered by a certain date?
  • Standard e.g. First In First Out (FIFO).
  • Intangible
  • Is it a nice to have?
  • Is it chargeable?
  • “Google Time”

Fixed delivery date could be regulatory or seasonal related, for example Christmas, Goldratt talks about this as self expediting. Pull by the oldest item when looking at fixed delivery date. Have a certain portion of standard class items on the board as these can be cannon fodder for higher class items, as they should have a low cost of delay. Intangible items may include production bug fix requests, usability improvements, branding and design changes and their like. These may come with their own classes of service, for example bug fixes may be given different classes of service based on severity. Its recommended to have between 3 and 6 classes of service.

You can have Kanban limits not just on each state on the Kanban board but also on each of the classes of service, for example a limit on non chargeable work.

Classes of service  work through the use of color to delineate the class, and simple prioritization policies that can be used by anyone to make a properly risk aligned prioritisation decision, in the field, on any given day, often without any management intervention or supervision.

Polices can include; prioritisation, limits, time and risk constraints, order, colours and annotations. As a good guideline you should look to have no more than 6 policies per class of service.

Policies will be unique in your project, however here are some examples:

  • Are there any fixed delivery items that need to be pulled now into the Kanban system?  Pull this in preference to other items regardless of priority
  • If a request meets a certain criteria then it gets a faster class of service on the board
  • Expedite / fast track prerequisites
  • Only 1 expedite request on the whole board
  • At least 4 standard items
  • If total WIP is 12 and we have a policy that 50% will be high priority then we want to ensure that 6 items are high priority.

Work items should flow through the system in a risk optimal fashion, and the result should be risk optimal releases of software, which maximise business value and minimise cost of delay penalties.

Tactical business pressure is dealt with via classes of service. If something is needed faster it is processed with a higher class of service. Ensuring that all the really important things are on time enables a far better conversation with the customer and maximises their satisfaction.

Label each of your backlog items against a class or service, either all upfront, in batches, or just in time.
You can even use classes of service to help manage shared or scarce resources.

Look to report by class of service

  • Work in Process
  • Cumulative Flow
  • Report on age of items (that are on the board)
  • Due Date performance vs SLA as a %

Corey Ladas writes

If you look at the cycle time histogram in Benjamin Mitchells article, you see two (or possibly three) very distinct groups of work items. That’s exactly the kind of information I’d hope to extract out such a study.

What do the work items in those clusters have in common? There are your service classes.

About these ads

10 thoughts on “Classes of Service and Policies

  1. Pingback: Kanban Results « Lean and Kanban

  2. Pingback: The Cost of Hidden Work « My mind wonders…

  3. Pingback: Pimp my Team - Zsolt Fabók's Page

  4. Pingback: Explicit Policies Make Life Simpler « Becoming an Agile Family

  5. Pingback: Réussir des « standup  efficaces autour du tableau Kanban « DantotsuPM.com

  6. Pingback: Réussir des « standup  efficaces autour du tableau Kanban « Monsieur Fredd

  7. Pingback: Réussir des « standup » efficaces « Eric's Blog

  8. Pingback: Kanban Software Development with GreenHopper | Nicholas Muldoon

  9. Pingback: Kanban Software Development with GreenHopper | Nicholas Muldoon

  10. Pingback: Você não sabia que o suporte é a parte mais importante do trabalho de um desenvolvedor? | iMasters

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s