Lately I've encountered several teams that organize their work using Agile methods and they all exhibit a similar pattern. Teams (or actually the work) having such work patterns I call Business Support Teams. This type of team usually is responsible for operating the application, supporting the business in using the application, and developing new features on top of the (usually third party) application,

The nature of the work may be plannable or highly ad hoc, e.g. production incidents and/or urgent requests from the business. In practice I notice that the more ad hoc type of work the team has to deal with, the more they are struggling with approaches based on a single backlog of work.

In this post I'll show a set-up using boards and agreements that works for these type of teams very nicely.


In practice teams that start with Agile often default to using Scrum. It initially provides a structure for teams to start off and sets a cadence for frequent delivery of work and feedback loops. Such teams often start with a 'typical' scrum board consisting of 3 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 2 or sometimes 3 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

What makes the Business Support Team different from other teams is that besides the list of features (application enhancements) they have other types of work. Typically the work includes:

  • Requests 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

This 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 and such,
  • Long waiting times for information and/or reports.

On the other hand, the team itself may experience that:

  • Work needed to keep the application operational limits the capacity severely to work on new features,
  • Interruptions due to incoming requests and/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

The expectations from the customer with regards to the work items typically are (but may vary)

  • Requests for information, e.g. reports,
  • Nature: Ad hoc, and may varies;
    Expectation: typically ranges from 1 week to 1 month
  • New features to accelerate the business,
    Nature: Continuously entering the backlog;
    Expectation: is predictability
  • Keeping the application and platform operational
    • Daily and routine operational 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: be able to spend time on it regularly
  • Keeping the application and platform operational
    • Handling production incidents
    • Expectation: as least as possible to disrupt the team

The challenge for the team is to be predictable enough regarding lead times for New Features while at the same time be able to take up work that requires immediate attention and at the same time have acceptable lead times on business requests.

Board & Policies

A board and set of policies that work very well are is shown to the right.kanbanized


The columns are kept the same as what the team already has. The trick to balancing the work, is to treat them differently. The board set-up above 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 1 work item at all times.

(Regular) Changes: Holds regular type of work which needs to be 'predictable enough'.

Urgent: Work that needs to be delivered with a certain service. E.g. within 5 working days. Mainly business requests for information, support and may include problems with priority levels lower than 1 😉

Operational: Meant for all tasks that are needed to keep the application up & running. Typically daily routine tasks.

Note: Essential to make this working is to agree upon WiP (work in progress) limits and to set criteria when work is allowed to enter the lanes. This is described in the section below.

Note: As mentioned above this basically follows the pattern of [Beaumont2015] with the row for 'Urgent' work added.

Policy Example

As explained in [Beaumont2014] the Definition of Ready and Definition of Done guard the quality of work that enters and leaves the team respectively.

legendaDefinition of Run

Specifies the state of the application. What does it mean that it is 'running'? Work items that bring back the system into this state goes into the Expedite Lane. Example:

  • Application is up & running,
  • Application's response is within ... seconds,
  • Critical part of application is functioning,
  • ...

Note: There is one other type of that is usually allowed in this lane: items that have a deadline and that are late for delivery....and have a policy in place!

Definition of Change

Regular requests for new features and enhancements. Predictability is most important. Certain variation of the lead time is considered acceptable.

Service level is ... weeks with 85% on time delivery (1 standard deviation service level).

Definition of Request

Business requests. Typical use includes requests for support, creation of reports (information) (e.g. national banks may require reports as part of an audit). And other types of requests that are not critically important to go into the expedite lane, are more than a couple of hours of work, and for which lead times are expected that are considerable shorter than that for changes.

Example criteria:

  • Business requests, requiring less than 1 week of work, or
  • A problem report with 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 2 hours of work, and
  • Routine task as described in the Way of Working, and
  • Can be started and completed on the same day,
  • Maximum of ... hours per day by the team.

It is 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.


From all the aforementioned work item types, only the 'Change' item is plannable; 'Run' items are very ad hoc from its 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 of work needs to 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. This will effectively divide the available team's capacity between the work item types.


Business Support Teams follow a pattern very similar to that described in [Beaumont2015]. In addition to the 'Run', 'Change', '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. These types are treated differently because they have a different risk profile (Class of Service).

This enables the team to be predictable enough on 'Changes' with an (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, while at the same time be able to have a fast as possible delivery of 'Run' items.

Allowing a larger variation on the 'Change' items allows for a higher service on the 'Request' items.


[Beaumont2014] The 24 Man DevOps Team, Xebicon 2015, Serge Beaumont, Link