{"id":5159,"date":"2016-03-08T14:52:46","date_gmt":"2016-03-08T17:52:46","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=5159"},"modified":"2016-08-18T16:15:05","modified_gmt":"2016-08-18T19:15:05","slug":"looking-at-lead-time-in-a-different-way","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2016\/03\/looking-at-lead-time-in-a-different-way\/","title":{"rendered":"Looking at Lead Time in a different way"},"content":{"rendered":"

As we discussed previously in the post Learning with Lead time<\/a>, analyzing the metric distribution regularly could be a useful tool to improve your software development process.<\/p>\n

Before continuing this blog post, I would like to suggest you an interesting read about the questions that surround the definition of Lead time<\/a>.<\/p>\n

At Plataformatec, we have been using Lead Time <\/strong>as the number of workdays between the beginning and the end of an issue (e.g., user story). In other words, as the Thomas reference, we use the concept of Production Lead Time <\/strong>(the clock starts when work begins on the request and ends when the item is delivered. In software development this is sometimes called \u201cEngineering Lead Time\u201d and in Manufacturing \u201cManufacturing Lead Time\u201d).<\/p>\n

Usually, when you plot out the Lead Time data on a histogram, you would expect to see the preponderance of the frequencies nearby the average value, with about half of the distribution above the average, and half below, as you can see in the images.<\/p>\n

\"normal-symmetric-distribution\"<\/p>\n

This scenario is common when you are dealing with a normal or symmetric distribution. However, you will observe a slightly different pattern when you study the Lead Time distribution of an agile team.<\/p>\n

\"lead-time-distribution\"<\/p>\n

As we know, a software development process has different characteristics if compared to the standard manufacturing process (e.g., work items follow one of many possible sequential processes; the effort for each process step is different for each work item; work has a natural uncertainty that brings variability for the system).<\/p>\n

Studying a little bit more about software development distributions, I found Weibull<\/a>, a type of distribution that has been used in life data analysis.<\/p>\n

According to Alexei Zheglov<\/a>,\u00a0Weibull is a family of distributions, parameterized by the shape parameter (\u03b2) and the scale parameter (\u03b7). It can assume the characteristics of many different types of distributions because changing the \u03b2 can tweak the shape of the distribution curve.<\/p>\n

When \u03b2 is equal to 1, Weibull<\/strong> is identical to the exponential distribution. In the other case, when \u03b2 is equal to 2, Weibull is just like Rayleigh distribution, and is possible to interpolate\/extrapolate those distributions for other values of the\u00a0parameter.<\/p>\n

To learn more about the impact of the parameters on shapes, I recommend you to read the paper written by Troy Magennis<\/a>.<\/p>\n

Trying to make the following content easier to understand, I will use in the rest of this blog post a set of data from two Plataformatec projects as examples to explain the concepts. The next table summarizes the project’s context.<\/p>\n

Project information<\/h3>\n\n\n\n\n\n\n
 <\/th>\nProject A<\/th>\nProject B<\/th>\n<\/tr>\n
Team process<\/td>\nScrum<\/td>\nKanban<\/td>\n<\/tr>\n
Project type<\/td>\nGreenfield<\/td>\nGreenfield<\/td>\n<\/tr>\n
Backlog size (amount of user stories)<\/td>\n66<\/td>\n40<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Lead Time Histogram<\/h3>\n

\"histogram-lead-time\"<\/p>\n

\"histogram-of-lead-time\"<\/p>\n

First of all, we need to eliminate the use of average<\/strong> when the team is discussing trends or when they need to estimate a user story deadline.<\/p>\n

As I said at another opportunity, using average in a non-Gaussian distribution is not a good \u00a0practice<\/a> and for those cases, analyzing the median and percentiles are better\u00a0approaches to advise the team when they need to estimate the time that will be necessary to create new features in the future.<\/p>\n

Let’s see this in more detail, based on the examples.<\/p>\n

Average, mode and median<\/h3>\n\n\n\n\n\n\n\n\n\n
<\/th>\nProject A<\/th>\nProject B<\/th>\n<\/tr>\n
Average Lead Time<\/td>\n14.8 days<\/td>\n7 days<\/td>\n<\/tr>\n
Mode<\/td>\n8 days<\/td>\n4 days<\/td>\n<\/tr>\n
Median<\/td>\n10.5 days<\/td>\n5 days<\/td>\n<\/tr>\n
Percentile 68 (Good estimation)<\/td>\n18 days<\/td>\n8 days<\/td>\n<\/tr>\n
Percentile 80 (Safety estimation)<\/td>\n20 days<\/td>\n10 days<\/td>\n<\/tr>\n
Percentile 95 (Pessimist estimation)<\/td>\n36 days<\/td>\n16.05 days<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In both projects, if the team uses the mode (the value that appears most often in a dataset) to forecast the lead time of new features, they will be estimating a time that is lower than the median (the number that is halfway into the set).<\/p>\n

On the other hand, the average will not be a good reference because looking to the distribution it’s clear that the dataset values aren’t nearby it.<\/p>\n

At Plataformatec, we are using three ranges of percentiles (a measure used in statistics indicating the value below, as determined by a given percentage of observations in a group of observations) to understand the behavior of the Lead time of our teams.<\/p>\n

On the Project A example, the team could provide a good estimation to the Product Owner, when they indicate a range of 18 to 20 days to conclude new user stories, because only 20% of the user stories developed by the team had a Lead Time higher than 20 days.<\/p>\n

At this point I guess you are thinking: “Okay, Raphael, now that you proved to me that Lead time distribution is far from being a normal one, how can I get some insights from my distribution?<\/strong>”<\/p>\n

To answer this question, we first need to validate if our Lead Time Distribution is a Weibull. The table below shows the project’s parameters and to get that information I used some R code and the spreadsheet developed by Alexei Zheglov<\/a>.<\/p>\n

Weibull parameters<\/h3>\n\n\n\n\n\n\n
<\/th>\nProject A<\/th>\nProject B<\/th>\n<\/tr>\n
Shape<\/td>\n1.47<\/td>\n1.5<\/td>\n<\/tr>\n
Scale<\/td>\n15.81<\/td>\n7.22<\/td>\n<\/tr>\n
R-squared<\/td>\n0.98<\/td>\n0.93<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In both cases the Weibull distribution fit well for the dataset (If the match is perfect, the r-squared number will be equal to 1). After analyzing an amount of different datasets, Alexei Zheglov<\/a> observed some characteristics based on the shape parameter.<\/p>\n\n\n\n\n\n\n
Shape<\/th>\nMeaning<\/th>\n<\/tr>\n
Less than 1<\/td>\nThe distribution curve is convex over the entire range. This shape parameter range occurs often in IT operations, customer service and other fields with a lot of unplanned work.<\/td>\n<\/tr>\n
Between 1 and 2<\/td>\nThe curve is concave on the left side and through the peak and turns convex on the back slope. This shape parameter range occurs in product development environments.<\/td>\n<\/tr>\n
Greater than 2<\/td>\nThe curve is convex on the left side, then turns concave as it goes up towards the peak, and turns convex again on the back slope. This distribution shape often occurs in phase-gated processes (waterfall).<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In both cases, the shape was close to 1.5 which means a concentration of lead times on the left side of the curve. The shape parameter defines data distribution, but does not affect its location or scale.<\/p>\n

Something interesting to share is that as mentioned at the beginning of the text, both projects were greenfield<\/strong> type, which is consistent with the classification presented above (product development environments).<\/p>\n

Based on the shape of the curve (1.47) and the scale (15.81) it is evident that project A worked with long items, which should have generated a great WIP. This type of situation typically occurs when there is a large number of external dependencies and delays over the process.<\/p>\n

With these parameters in hand, you as an Agile Coach could identify and help the team to remove impediments and delays, as well as decrease the value of the scale parameter and bring greater predictability to the development process<\/strong>.<\/p>\n

In the case of project B, we have an interesting combination of shape (1.5) and scale (7.22) because rarely in a context of a product development, the team could have a different lead time distribution format.<\/p>\n

Summary<\/h2>\n

In this blog post, I tried to bring a new way of analyzing Lead Time<\/strong>.<\/p>\n

As software developers, we deal with some uncertainties, questions, and changes that produce high variability in our process.<\/p>\n

Learning to understand and interpret the data extracted during development allows us to discuss ways to optimize and continuously improve something that is, in essence, complex (and fun), that is to build solutions.<\/p>\n

Understanding how to estimate the correct parameters of the distributions has been significant for the exercises we have done at Plataformatec, creating quantitative models to predict delivery dates.<\/p>\n

Good reading recommendations on this subject are:<\/p>\n