Development groups tend to deal with different types of requests. These include enhancements, new products, severity one errors, etc. It is important to distinguish between these different types of classes so that they can be worked on appropriately. The agreement between the requester (usually Discovery) and the group that will be taking the request (usually Implementation) is called a service level agreement.

One of the first steps in creating the set of agreements between Discovery and Implementation is identifying both the classes of services and the service level agreements. Here is a first cut at both of these. Please add comments and/or make suggestions (with track changes on).

Who Does This Practice

Here are roles involved in this practice:

What To Do

Inputs

Inputs to this practice include:

Release dates with any specific delivery requirements or commitments
Emergency requests, such as critical defects, technical debt that’s hit home

Approach

To develop a list of the Classes of Service:

Classify all work items in existing work backlogs into Classes of Service
Identify unique policies for work on each Class of Service. These are called service level agreements (SLAs)

Analyze value items (Capabilities, MBIs, Features, Stories) for how they are sensitive to time (primarily) or other special handling. For instance, some common Classes of Service include:

Identified Service Classes

MBIs (enhancements, includes NFRs) without fixed dates
MBIs with fixed dates. Work with a hard date of delivery such as a Trade Show or a regulatory deadline.
MVPs (innovation / new)
Severity 1 errors. Something has gone wrong and needs to be fixed immediately.
Maintenance/ Bugs-errors
Expedited (executive directive), High-priority unscheduled work, not anticipated due to new circumstances or deficient strategizing or planning (in the latter case, good source for process improvement ideas).
Accelerated. Somewhat like expedited, but don’t stop work to do it, just have the work go to the front of the line.
Interruptions: While you may do these the same as other classes of service, it is worth treating them as a special case because the frequency of these should be managed.
Interruptions: While you may do these the same as other classes of service, it is worth treating them as a special case because the frequency of these should be managed.

Discussion

A completed list of Classes of Service includes:

The list of Classes of Service, with definitions of each
Any policies unique to handling work items in a given Class of Service

Examples of policies:

A policy for when an Expedite item can interrupt a work item of another type (e.g., Standard Business) already underway
A policy for how to allocate the available capacity of the team across all types of Classes of Service (e.g., “20% of capacity goes to change items”)

When To Do This Practice

During the initial analysis of an organization’s or team’s work, generally at the same time as Value Stream Mapping

Where To Do This Practice

Identifying Classes of Service is done in conjunction with the members of the organization or team.

Outcomes

Here are some expected outcomes from this practice:

Work is completed when needed, with minimal disruption to other work
Work of all classes of service is performed with the optimal mix between them
Work of different types of time criticality need to be handled in different ways, to complete everything when it is needed. Classes of Service makes this visible and explicit.

Classes of Service Checklist

This section is used by people doing DA FLEX to specify their agreed upon classes of service and optionally their service level agreements for each class.

This section (from this point to the end) can be freely copied and modified for use by someone using DA FLEX.

Class of service ________________________________________

Description __________________________________________

_________________________________________________

Service Level Agreement for this class of service