Flow efficiency
Last updated
Last updated
Efficiency reflects how much work time is spent in a normal, flowing state—that is, issues moving left to right through your Jira statuses—versus those that have fallen into an exception states. Where possible, Socratic infers these exception states automatically:
Rework: that is, issues that went backward in the workflow, either from a later active status (e.g. "Testing") to a prior one (e.g. "In Development"), or from the Done status back to an active status.
Deprioritized: this is any issue that moves from an active (In Progress) status back to a waiting (To Do) status.
Issues that become blocked. This is the one state we can't infer by ticket movement. When you mark a ticket as blocked in Jira, we track the amount of time it spent in that blocked state.
Bear in mind, efficiency is a measure of time worked by state, not ticket counts. For example, if an issue takes 5 days to move from start to finish, but along the way is blocked for one day, its flow efficiency is 80 percent. Four of its five days (80%) were in a normal, flowing state, with one day (20%) in a blocked state.
Burning worked time in exception states—blocked, deprioritized, rework—is a natural part of software engineering. The target of efficiency is not and should not be 100 percent. The aim is simply to understand how much time is spent in any of these exception states, and to mitigate it whenever it appears high. For our own work at Socratic, we target an average efficiency around 90 percent.
See also our Methods post: Unstuck: finding flow in software engineering.
