short link: http://goo.gl/8ndQoK
Also Known As:
Motivation: Not all items on a backlog are necessarily subject to the same terms of service. Examples include enhancements and defect fixes, the impact or severity of which may vary. The quality of service provided to those backlog items must therefore be allowed to vary as well. Note that this motivation typically applies to Business As Usual workstreams such as technical support. The quality of project work should be invariant.
Structure: A team selects which items from a backlog to action according to the prescribed Quality of Service and only then will the order of items be considered. The Work In Progress limit may be revised to support the terms of service of a selected item.
Applicability: Quality of Service is applicable to situations where the handling of work varies by context. Examples include Service Level Agreements, where the demands of certain clients may be prioritized over others; variations in the skills or technologies required for the implementation of a backlog item; or the prioritization of emergency work over that which is in progress.
Consequences: Quality is no longer invariant. The order of backlog items only partly indicates their relative priority since their Quality of Service is also considered.
Implementation: Quality of Service is allowed to vary in most Lean-Kanban implementations. These teams provide Business as Usual work in a support context. This pattern is not found in DSDM, XP, or Scrum as these methods hold quality to be invariant. Hybrid Scrum-Kanban implementations that allow the Quality of Service to vary (for example by supporting a “fast track” or “expedite” class of service) are widespread.