The Legacy We Build Upon

The topic of lean metrics requires an understanding of the influence of Kanban and the Toyota Production System. Scrum, as an agile process framework, was built as a lightweight version of the TPS Kanban practices that anyone could use, while Atlassian developed JIRA to enable visualization of any process, regardless of its complexity.

The “priority” field originated as part of Jira’s oldest legacy as an issue-tracking system. Greenhopper was a plug-in that enabled the issue-tracking database and web services to be used for Lean-Agile teams. Greenhopper created a new front end for the data in JIRA – namely, the work-in-progress board and the product backlog – so that a Scrum team or Kanban team could use JIRA for agile.  Ultimately, this became synonymous with JIRA and the today it ships with the agile front end OOTB.

In Scrum, the Product Backlog is used for prioritization, so the “priority” field has little meaning. In Kanban, the priority field is used to create swim-lanes based on Classes of Service.

Expedite Anything That Blocks Value Creation or Capture

“Blocker” would indicate that WIP limits can be violated and workers should interrupt their current work in favor of Expediting the blocker through the system so it doesn’t not cause long-running damage to continuous flow. The equivalent in Scrum is building out a process for stories, tasks, or bugs that are allowed to violate the Sprint commitment. In either case, the goal is to recognize that this is costly and unhealthy, an exception to normal rules. Unless it is a production defect, some element of the expedite cost should levied against the person demanding special treatment.

Flush the System of Any Critical Items that Disturb Continuous Flow

“Critical” would indicate that a card should “jump over” all other items at each step in the process, but it should not interrupt work or violate WIP limits. These items get to cut to the front of the line, but are not allowed to interrupt completion of existing efforts. The equivalent in Scrum is building out a process for what items, if any, are immediately prioritized to the top of the Product Backlog. It is typical for this to be a “Fixed Date” class of service – because fixed dates are the most consistent destroyer of sustainable flow, we want to get those things out of the way quickly so that the system can return to normal.

Everything Else Follows the “Normal” Process

“Major” and “Minor” and “Trivial” are typically part of the same Standard (aka normal) Class of Service. If used in Scrum, it is primarily for the benefit of the Product Owner to visualize previous conclusions about prioritization. In Kanban, these are meant to respect all WIP limits and follow a First-In-First-Out (FIFO) method at each step in the process.