Teams that organize plannable or ad hoc work using Agile methods often exhibit a similar pattern. If they’re usually responsible for operating the application, supporting the business in its use, and/or developing new features on top of a (usually third-party) application, I call them “business support teams.” I’ve noticed that the more ad hoc type of work these teams have to deal with, the more they struggle with a single backlog approach for managing it.
In this post, I’ll show you how business support teams such as these can use a particular set-up of boards and agreements to get a handle on their work.

Kick-Off

In practice, teams that start with Agile often default to using Scrum. It initially provides a structure and sets a cadence for the frequent delivery of work and feedback loops. Such teams often start with a "typical" Scrum board consisting of three lanes: "to do," "in progress," and "done."
Here, the team has a backlog consisting of features to support the business, a visual board with three lanes, "definition of ready," "definition of done," and a cadence of two- or sometimes three-week sprints.
Note: the "definition of ready" is not part of Scrum, and a good practice often used by Scrum teams. See also this blog.

Business Support Team

A business support team is different from other teams in both its list of features (application enhancements) and the types of work it does, including:

Request for information, e.g., reports
New features to accelerate the business
Long-term improvements
Keeping the application and platform operational
Daily and routine operational jobs
Handling production incidents

The work follows the pattern described by Serge Beaumont in this presentation with the addition of "business requests" (requests for information).

Commonly Encountered Dissatisfactions

From a business point of view, the customers may experience any of the following:

Unpredictable service as to when new features become available
Limited support for questions
Long waiting times for information and/or reports

On the other hand, the team itself may experience :

Severe limitations in their capacity to work on new features (because of the work needed to keep the application operational)
Interruptions due to incoming requests or incidents that require immediate attention causes longer lead times
Too much work in progress
Pressure to deliver for certain groups of business users will be at the cost of other stakeholders.

Business Expectations

Customer expectations with regards to the work items may vary but typically include:

Requests for information, e.g., reports,
- Nature: ad hoc, and may vary
- Expectation: typically ranges from one week to one month
New features to accelerate the business
- Nature: continuously entering the backlog
- Expectation: predictability
Keeping the application and platform operational
Daily operational and routine jobs
- Expectation: just to have a running platform 😉
Handling production incidents
- Expectation: as fast as possible

From the team’s perspective:

Long-term improvements
- Expectation: to be able to spend time on it regularly
Keeping the application and platform operational
Handling production incidents
- Expectation: the least possible team disruptions

The challenge for the team is balancing between having predictable lead times for new features, work that requires immediate attention, and acceptable lead times on business requests.

Board & Policies

Board and set of policies that work well shown below:

kanbanized

The columns are the same, but the work is balanced differently. The board set-up has four lanes:
Expedite: Reserved for work that needs to be dealt with immediately, e.g., production incidents. Sometimes also called "Fast Lane." Maximum of one work item at all times.
(Regular) Changes: Holds regular types of work, which needs to be "predictable enough."
Urgent: Work that needs to be delivered with a certain service, e.g., within five working days. Mainly business requests for information, support and may include problems with priority levels lower than one. 😉
Operational: Meant for all tasks that are needed to keep the application up and running. Typically, routine daily tasks.
Note: Essential to making this working is to agree upon work in progress (WIP ) limits and to set criteria when work is allowed to enter the lanes, as described in the section below.
Note: As mentioned above, this follows the pattern described in the presentation with the row for "Urgent" work added.

Policy Example

As explained in the presentation the "definition of ready" and the "definition of done" guard the quality of work that enters and leaves the team respectively.
legenda Definition of Run
Specifies the state of the application- what does "running" mean? Work items that bring back the system into this state go into the "expedite" lane. Example:

Application is up & running
Application’s response is within … seconds
Critical part of application is functioning
…

Note: One other type of item is usually allowed in this lane: those that have a deadline and are late for delivery–and have a policy in place!
Definition of Change
Regular request for new features and enhancements. Predictability is most important. Some variation of the lead time is considered acceptable.
Service level is … weeks with 85% on-time delivery (one standard deviation service level).
Definition of Request
Business requests. Typical use includes requests for support, the creation of reports or information (e.g., national banks may require reports as part of an audit). Also, other types of requests that are not critically important enough to go into the expedite lane, and are more than a couple of hours of work. For these, lead times are expected but are considerably shorter than those lead times needed for changes.
Example criteria:

Business requests, requiring less than one week of work
A problem report with the severity of 2, 3, or 4
Service level is …. working days with 95% on-time delivery

Definition of operational
Describes the routine tasks that need to be done regularly to keep the system running as stated in the "way of working."
Example criteria:

Less than two hours of work
Routine tasks as described in the “way of working”
Can be started and completed on the same day
Maximum of … hours per day by the team.

It’s important to limit the amount of time spent on these items by the team so the team can maintain the expected service levels on the other types of work.

Cadences

From all the work item types mentioned above, only the "change" item is plannable. "Run" items are very ad hoc by nature, as is the case with "operational" tasks (some are routine and some just pop-up during the day). Requests from the business tend to come in on short notice with the expectation of short delivery times.
Because of the "ad hoc" nature for most work item types, planning and scheduling must be done more often than once every sprint. Replenishment of the "to do" will be done continuously for the rows whenever new work arrives. The team can agree on a policy for how often and how they want to do this.
The sequence of scheduling work between the rows is done either by the product owner or self-regulated by a policy that includes setting WIP limits over the rows. It will effectively divide the team’s available capacity between the work item types.

Summary

Business support teams follow a pattern very similar to that described in the presentation. In addition to the "run," "change," and "operational" types of work, the type "request" is identified. The work is not described by a single backlog of similar work items but rather as a backlog of types of work. The way teams handle these types is different because each has a different risk profile (class of service).
A backlog of types of work enables the team to:

Be predictable enough on “changes”
With a (not so small) acceptable variation of the lead time
Have a higher service level on ad hoc requests from the business (“request”)
Plan their daily routine work
Deliver “run” items as fast as possible

Allowing for a more significant variation on the "change" items allows for a higher service on the "request" items.

The Business Support Team Pattern