Chapter 8. Classes of service

This chapter covers

• What a class of service is
• Putting classes of service to use for you
• Examples of commonly used classes of services

In the previous chapter you learned different ways to manage the flow of work. One thing all those different principles, rules of thumb, and good practices didn’t address was that not all work items are of equal importance. Some types of work may need to flow faster through the workflow than others. This is where the concept of classes of service comes in handy. Let’s start with an example of a pretty standard case.

8.1. The urgent case

The case of a particularly urgent work item is a well-known one to many teams; there’s often a need to be flexible with your process to allow for important and valuable exceptions to your normal rules and policies. It could be a production issue, a fix needed to comply with a regulation or a contract, a business opportunity you have to act on fast—anything that makes it reasonable to drop what you’re doing to drive this work item to completion as fast as possible. A common way to visualize this is to add a special lane on the board to make it clear that it’s a different class of item with special policies attached to it. Be explicit about what these policies are—here’s an example we’ve seen:

Urgent items:

• Have their own swim lane
• Are written on pink stickies
• Don’t count against the WIP limits
• Should be prioritized above regular items; in fact, everyone should drop what they’re doing and help fix this issue (also called swarming; see section 7.2.3)
• Only need a rough estimate to see if they can be delivered in time for a particular due date
• Should be exceptions; for example, only one urgent item in its lane at any given time, and a maximum of two per week

The last point can be of particular importance in environments in which the cost of expediting the item isn’t immediately apparent to the people pushing the urgent work items through the system. If you remember Little’s law (from chapter 5), you might recall that adding more work will cause longer lead times for all the work in your process. Using kanban to visualize this may help people understand this and avoid unnecessarily expedited work.

Kanban helps you point out that urgent items are, and have to be, exceptions.

A Word from the Coach

To make sure the Urgent class of items doesn’t get overused and to help us improve and learn from this exception, we have recently started to introduce an extra activity that is done after every urgent item: a short retrospective or root-cause analysis. Because such items are exceptions, you should treat them as holding nuggets of knowledge that you need to harvest to improve your process. Hence, after every urgent item is completed, you get together for a retrospective:

• What in our process made this urgent item occur?
• How can we prevent this from occurring again?
• Did our handling of this item work out as planned?

We’ve also found that some stakeholders reclassify their urgent items when they’re informed that we intend to discuss those items in a retrospective meeting after we’re done with them. Maybe it wasn’t that urgent after all! And that was what we wanted; Urgent is for urgent things only. It isn’t a fast-lane access to the team to get “my items” done faster.

Urgent, sometimes also referred to as Expedite, is just one example of a class of work items with different policies from regular items. You could say that these work items have a different class of service.

8.2. What is a class of service?

What you do with the Urgent class is to explicitly state that a certain class of work items gets certain service. As it turns out, not all work items necessarily have the same level of value or time pressure. You want this to be reflected explicitly on your board and in other work policies. This is why classes of service have become an important concept in the kanban community.

Assigning different classes of service to different work items is an easy way of creating a simple and transparent approach for the team to self-organize around the work and to meet the needs of the business by making work-item value, risk information, and policies explicit—maybe even visualized on the board. It also helps increase customer satisfaction by using different service levels for different types of work.

Let’s take a look at some aspects to consider when capturing and visualizing different classes of service.

8.2.1. Aspects to consider when creating a class of service

As you can see in the example of the Urgent class of service, there are many aspects of a work item’s behavior that you can consider when capturing or creating a class of service. Here are a few examples of aspects that a class of service can affect.

Visualization

In order to easily see a work item’s class of service, you want to make it visual to all members of the team as well as other people who might be interested. One way is to use a swim lane, as in the Urgent example. You can also use a special color for the work item’s sticky or indicate the class of service on the work-item card somehow—for example, with a sticker or an icon.

Impact on WIP

Does the class of service have an impact on the WIP limit or not? Does the class of service impact WIP in some columns and not impact WIP in others? If the class of service has its own lane, does that lane have a WIP limit or a maximum number of items? A minimum?

Prioritization

How is the class prioritized compared to other classes? Should work items of this class be pulled before other classes? Does it have a swarming policy so that other work should be dropped and everyone swarms to pull this through the workflow as fast as possible? Maybe a First In, First Out (FIFO) type of queuing would be a suitable policy for this type of work.

Risk information such as cost of delay, special skill requirements, and technical impact are typical considerations to make explicit, to empower and assist team members to make good risk decisions just in time.

Different workflow

Should the class follow a different workflow than other classes? Maybe it skips a column: for example, no analysis is needed for items in the Defect class of service. Maybe it has a different policy for one step of the workflow: for defects, a non-QA developer may do the QA work. Maybe it needs less-detailed estimation than other classes.

Change the workflow for your classes of service to optimize the outcome of items by the class of service. For urgent items, you could optimize for speed, whereas items that are classified as intangible might have code quality as their primary outcome.

With these aspects in mind, let’s take a closer look at a number of classes of service that are commonly used in the kanban community.

8.2.2. Common classes of service

In addition to the Urgent class, which we mentioned already, there are a number of other common classes of service. Among the most widespread are the classes of service that David J. Anderson describes in his book Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010): Expedite (which we call Urgent), Fixed Delivery Date, Intangible, and Regular (Anderson uses Standard, but we prefer Regular to avoid confusing it with the Lean concept of standard work). In our description of the different classes, we have also added a class for Defects because it’s a common class of service in many organizations.

This section takes a closer look at these classes of service. If you don’t find them fitting for your specific situation, please elaborate and change them as needed. Use the guidelines here as an inspiration, and make them suit your situation better.

Fixed Delivery Date

The Fixed Delivery Date class of service is used when something has to be delivered on or before a specific due date. The work item must be prioritized and pulled through the workflow in time for this date, because a failure to do so typically is met with increased costs or missed opportunities. Contractual or legal obligations are examples that easily come to mind, but there can also be technical reasons such as discontinued support of a third-party service on a certain date.

With a Fixed Delivery Date class, you need to schedule the items in time for the due date—but not too early, or the items will delay other, more valuable work.

Fixed delivery date items could have these properties and policies:

• Are written on purple stickies
• Have the due date clearly stated on the card
• Will be pulled in preference to other, less risky classes: for example, in preference to everything except Expedite

  

• Should be considered for promotion to the Expedite/Urgent class if the due date is threatened

Warning

Don’t overuse this class and turn your work items into tasks in a traditional plan-driven Gantt chart.^[1] Use it sparingly for external due dates and similar constraints, or you’ll mess up the workflow for the normal items.

¹ A Gantt chart is a type of bar chart that illustrates a project schedule and the dependencies between the different tasks in the project. The agile community shies away from Gantt charts because they make guesses and estimates about the future look like they are the future. Dan North even says, “Newborn children only fear two things: bright lights and Gantt charts.”

Regular items

The Regular class of service contains the bread-and-butter work items that fill up the workweek. Flow and focus will move these as fast as possible through the system and with reasonably predictable lead times.

Another term we’ve heard^[2] of for this class of service is Increasingly Urgent. Typically these items aren’t urgent right now, but as time goes by their urgency increases.

² Read more at http://mng.bz/P6M4.

We have often seen regular items used with the following simple policies:

• Are written on the ubiquitous yellow stickies
• Are pulled based on FIFO order: First In, First Out

Intangible items

Items of this class are those that don’t have a tangible, concrete business value, or at least not one that is easy to estimate, but which are still important. This includes things like low-priority defects, small usability improvements, and design changes.

This class also covers what Stephen R. Covey (author of The 7 Habits of Highly Effective People) calls important but not urgent tasks. They’re ones you’re likely to neglect but should focus on to achieve effectiveness: improvement work, removing technical debt, increasing medium or long-term capacity, and other things that will help you reduce future costs or create future options.

The low cost of putting off these tasks creates a temptation to put them off indefinitely, a day at a time. One way to avoid that is to ensure that there is always some capacity for this class of work. An added bonus is that doing this creates slack in the system that can be used to flow other classes through the system faster: for example, by pulling other classes before this one, if needed.

In organizations in which a product owner or external stakeholders select the team’s work, it isn’t uncommon to use the Intangible class as a way for the team to select items at their own discretion: for example, for reduction of technical debt and improvement work.

Items in the Intangible class could have these properties:

• Are written on green stickies
• Will only be pulled if there are no other class items available
• Might be limited in some way by number of items on the board (see section 8.2.3). For example:
  • Should always be two of them on the board
  • Should make up 20% of the story points for the iteration
  • Should have a rate of three items per month

The Intangible class of service can also take other forms, such as the famous Google time that allocated certain days for intangible work. Other forms we’ve seen are technical or improvement cards that the team creates: for example, the team may be allowed one “improvement card” on the board at all times. Some people call these technical gold cards, because it’s those golden nuggets of improvements that developers often long to tackle but never have time to work on.

Defects

Defects are the class of work that you don’t want to see. A defect is often a sign of some lack of quality in the work you did the first time around. In this form, it’s rework that is introduced and added to the work you’re already doing.

Defects can be other things as well, such as production bugs or a server failure that you need to handle immediately.

Here are some example policies for defect items:

• Are written on red stickies
• Skip the Analysis step and go directly to the Development column
• Don’t have to be estimated

  

• Should be subjected to root-cause analysis on how to avoid similar defects in the future before being pulled to Done
• Have to be managed in the bug-tracking tool: closed and assigned to QA, and so on
• Can be released outside the normal release schedule: they don’t have to wait for the next normal release

By now you’ve seen a lot of uses for classes of service and examples of commonly used variants; but why go through all this trouble to classify work items? What use can you get from classes of service?

8.2.3. Putting classes of services to use

Classes of services can help with a lot of decisions that you, as a team, will be facing. It’s all about making policies, work-item value, and risk information more explicit (see chapter 3), thereby helping the team to self-organize and pull the right work items. This in turn helps the work to flow more smoothly and quickly through the workflow, because you don’t need decisions or approval from others at every question or decision point.

One way to use classes of service is to decide how much of a team’s capacity should be used for different classes: for instance, by deciding on a number (or percentage) of work items per class that will always be on the board. Let’s see an example in action:

On this board, to the left, the team has posted a legend and the preferred distribution between the classes of services. You can see four classes of service in action here: Regular, Intangibles, Defects, and, finally, an Urgent swim lane for work items that have to be expedited through the workflow.

A percentage number and a concrete number are written beside each class of service in the legend. They indicate how you strive to have the work distributed. When you finish one work item, you can easily look at the board and see which card to pull next from the Todo column to keep the distribution as the team agreed.

From this example, you can see an explicit policy at work to help the team self-organize. With the help of the preferred distribution (percentages of each class of service), Beth could easily conclude what kind of work she should pull next. Using different colors for each class of service made this easy to see; Beth finished analyzing a yellow sticky, and to keep the proposed distributions of colors, she could count the work items and see that a red one was the one to pull.

But also, and maybe more important, this system made sure work was prioritized in a proper manner. The defect card that was waiting in the Todo column was prioritized over the others, ensuring that the team attended to defects, even though it might be more fun and even more important to the business stakeholders to work on new features.

Used like this, classes of service can also help you make sure low-priority work is at least getting done to some extent and not constantly deferred to “later.” In this example, the team is guaranteed to always have at least one intangible ongoing at all times. Because the intangible has a lower priority to be pulled to the next column while it’s in the workflow, it also creates some slack for more important work to move to Done faster.

The distribution of different classes can of course be continuously modified to allow for changing business needs. For example, if there is a perceived quality problem with the product, you may want to increase the ratio of defects until that is resolved. Or if the team has had to sprint to reach a deadline, maybe it’s time to dial up the number of intangibles and pay off the accumulated technical debt.

You’re aiming to get a better flow for the work items on the board. On many teams, the flow can be stalled for a simple reason, such as people not being present when needed for prioritization, for example. If you’ve ever experienced the need for a product owner to know what to work on next, and being stalled because she’s only present for a half hour each week on Tuesdays, you know what we mean.

With explicit policies in place, the coordination costs for selecting work are much lower. You have the principles for how to select work from the backlog in place already, often visualized on the board. The team is more self-organized and can do the selection just in time instead of batching up work in advance, just in case, as they would need to do with a stakeholder who is hard to get hold of.

The process of selecting the right thing to do, in the right order, at the right time, is called scheduling:

Scheduling is the process—and it’s an ongoing and dynamic thing—of producing economically optimal results from the sequencing of work items. It’s a big responsibility; so let’s try to do it in a robust and transparent way.^[3]

³ Read more at http://mng.bz/avnN.

Mike Burrows (@asplake on Twitter)

You’ll learn more about planning and scheduling work in chapter 9.

If you strive to have a quick flow with small batches (small-sized work items) through your workflow, you’ll minimize both transaction and coordination costs. This will happen through an ongoing and dynamic selection of work items to work with, rather than making plans for a future that might change. The tool to accomplish this is transparent, explicit policies, such as limiting the number of items that can be in a certain class of service on the board at the same time.

8.3. Managing classes of services

If you run into situations like the one the Kanbaneros are asking Joakim about, you’re not alone. Although the different classes of service might be clearly defined and agreed on by everyone, the work might not always fit your classification. For example, work items might consist of several tasks, each of which belongs to a separate class of service; or you might handle work items differently depending on where they come from. This section talks about a couple of common methods and practices that can help you handle these situations.

Divide and reclassify

Sometimes a single work item might be a mix of different classes of service, particularly if it’s a big work item. This might result in you having a hard time deciding which class of service the item’s in, and thereby being unsure how to handle it. It might feel like both a bug and an intangible at the same time. Try to break down big items like that into smaller ones, and see if the new items belong to other classes and should be treated accordingly.

Reasons for dividing work items and reclassifying the new work items are contextual and depend on the way you work, in the team and with your clients. Following are some common reasons that we see from time to time.

Size matters

Sometimes you can’t break big items down due to the nature of the work item or the dependencies in the technical environment or the organization. Other times, teams end up with some items that are an order of magnitude bigger or more complex than others.

It goes without saying that lead times for such big items will be different, and perhaps other policies apply. This can be a reason to consider a special class of service. Maybe you can allow a big item to be on your board for a long time and during this time always allocate a certain amount of work to it.

Some clients are more equal than others

Different clients can be more important than others, as typically represented by a different service-level agreement (SLA). You might want to favor a certain customer while securing the new contract with them, or perhaps one department or a specific product has been given priority over others in the company.

If the difference implies a different policy for how you treat work, a new class of service might be the solution.

Slicing it differently

Another way to differentiate between classes of service that could prove to be useful is to classify work based on its origin or the source of demand. In this way, you may end up with classes like Marketing, Customer Support Issues, and Developer Requests.

This is yet another way to classify the work items and make the policies around each class explicit. Which policies you associate with each class will vary depending on your context. But from the prior examples (see section 8.2.2), you can extract some common patterns that are easily applied to the classes of service that you find useful in your context.

Warning

Don’t overcomplicate things. A rule of thumb is to not use more than five to seven classes of service, because more than that makes it difficult for everyone to understand and remember them and to use the policies in daily decision making. Having said that, don’t be afraid to be imaginative and explore in order to understand how your work works.

Zoom in, explore, and simplify

With a lot of different ways to slice, divide, and change your classes of service, an obvious question is, how detailed should you get? We would like to quote a friend of ours to help explain that:

Zoom in (more columns/classes), explore, and then simplify is a pattern I’ve seen work.

Jabe Bloom (@cyetain on Twitter)

What Jabe Bloom means in the quote is to first detail and add stuff: more columns to your board and more classes of service, for example, to your policies and workflow. This forces you to explore and try different ways of applying these until you feel you have something that works for the team. Now try to simplify what you’ve created: what can be removed, which classes could be grouped together, and so on.

8.4. Exercise: classify this!

Sit down with your team, and start thinking about how classes of services can serve you:

• Should you use an Urgent swim lane? What kind of policies should surround that class of service? How do you make sure not everything is urgent? Can there be only one urgent item active at the time?
• Think about the different types of work you do; maybe you already have different colors for some of the work (bugs, for example). Are there any implicit policies that “everyone knows” that you could benefit from by discussing and writing them down?
• Do you have work that often is forgotten or that frequently gets low prioritization? Could a class of service and a policy around that help you get low-priority work done? Can you formulate that policy in words? What kind of visualizations can help you remember your policy and help you “fall in the pit of success”?
• What kind of policies do you have in place today that you could simplify?

8.5. Summary

This chapter talked about ways to associate explicit policies with certain types of work—a concept called classes of service:

• Classes of service are a powerful way to make your policies explicit around the service level for certain type of work.
• Assigning a class of service to a work item can influence the work item: visualization, prioritization, impact on WIP, and workflow.
• Classes of service help the team to self-organize around
  • Work selection and scheduling
  • Work distribution
  • Making sure the work capacity is distributed as decided
• Common classes include
  • Urgent (or Expedite)— Prioritized over other work
  • Fixed Delivery Date— Needs to be completed on or before a certain date
  • Regular— Normal items, increasingly urgent, pulled FIFO-style
  • Defects— Rework produced by bad quality (you want as few of these as possible)
  • Intangible— No tangible business value now, but later: paying off technical debt
• You should use classes that suit your needs and situation, using the examples in this chapter as inspiration. There’s no one right answer for everyone.

In the next chapter, we’ll take a look at another concept that is important for any process: planning and estimating. How does planning go together with kanban? Are estimates still important? Are there some common ways of estimating?