Last month the entire Tasktop Customer Success team met in Las Vegas ahead of DevOps Enterprise Summit 2018 for our annual face-to-face. During the meeting I had the opportunity to present Tasktop’s own journey into Value Stream Management and the Flow Framework™.
There were some great discussions around gathering data and measuring both flow time and lead time to help teams better understand how fast they are delivering customer-facing outcomes. Such data can be used to gain vital insights into how they can accelerate speed of delivery and time to value – insights that would elude them if they solely relied on anecdotal information.
One question from the day that struck me the most was, “Will lead time ever be part of the Flow Framework?”
Lead time vs. Flow time
Lead time measures the time elapsed from the point a piece of work – such as defect or feature – is requested (usually by a customer) to the point that it’s delivered. For example, a defect’s lead time starts at the point a customer reports the problem and ends when the fix has been delivered in a patch or version of the software. For new functionality requested, lead time would be measured from the moment a customer requests a new feature to the point it is made available in the software.
Flow Time, on the other hand, measures the time it takes for a work item to go from the point that it is accepted into the value stream – i.e., from its first “active state” – to when it’s available to the customer (deployed or delivered). Let’s break that down a bit. All work items go through various workflow states like New, In Progress, In Dev, In Review, Verification and so forth. These states can be generalized into four broad states:
- New (work item is created)
- Active (when value adding work is being carried out on the item)
- Wait (item is waiting on external dependencies)
- Done (complete state)
A work item can be “accepted” into the value stream at different points of the workflow. For example, incidents that are escaped defects (a bug found in software in production) will enter the value stream as soon as triage is complete and it is determined that a patch or service release is required. New enhancements may only be accepted into a value stream when it is scheduled in the backlog.
There is no right answer. The first “Active state” can start at different points, largely varying on the product and on the type of work. As flow time only starts from the first active state of the work item, the calculation of flow time excludes time taken for initial triage and business prioritization, but does include all states that the work item goes through across the lifecycle – from design, development, testing, verification through to delivery.
Mik Kersten, in his upcoming book Project to Product (which launches November 20), goes into some detail about lead time vs. flow time. Mik talks about open source projects that have a myriad of feature requests spread across a small number of developers. This means that some requests can sit in the backlog for long periods before work is ever started on them, elongating lead time (and time to value).
Trevor Bruner, Tasktop’s Product Manager of Tasktop Integration Hub, will tell you that Hub – which is in its second year – has about five years’ worth of features requested so far. In each of the above cases, a large part of the lead time that is calculated includes wait times before the request is triaged, approved and prioritized, and thus doesn’t truly represent the flow of value, or more importantly the cost of delay.
For products such as Hub, where the product manager has to carefully manage when features can be accepted for a build, flow time provides a more realistic view of the flow of value.
Within Tasktop, we categories certain requests as Deal Breaking Feature Requests (DBFRs), which are any type of product related request that, if not implemented, would cause a customer deal to be lost, a contract renewal to cancel, or the relationship to be irrevocably damaged. Sometimes these will need to be Fast Tracked (FT) into a current cycle due to urgent nature of the request.
Such requests that have a tighter correlation to business value (i.e., revenue of Hub) over regular features. The sooner these DBFR+FTs are delivered, the better impact they have on business value (increased revenues from renewals/sale). Hence the flow time for DBFR+FTs will start almost as soon as they are raised (with short triage times) and would trend closely to lead time demonstrating faster delivery of value.
So, as you can see, flow time is a better representation of business value. To circle back to the initial question “Will lead time ever be part of the Flow Framework?”, while lead time is an interesting measure from a customer perspective, and teams have derived a lot of insights on speed in delivery by measuring and reporting on it, flow time is more valuable from a business perspective. Even without lead time, the Flow Framework™ is powerful and flexible approach to meet the demands of products and individual flow items in a way that aligns with the most critical business needs.
To learn more about Flow Time, check out The 5 Best Metrics You’ve Never Met by Tasktop’s Director of Digital Transformation, Dominica DeGrandis, and speak to us about her Flow 101 Workshop.
