Our lead time increased. Why is it good?
I’m part of the Data team at Flowe, a group of 9 developers that is not just in love with analyzing data. We are actually in love with measuring and visualizing numbers that help us understand how our team is working. We work in Scrum and, during every sprint, we look at metrics like burndown charts or team velocity.
We recently starting monitoring the lead time of our features. The lead time is defined as the time that spans between the creation of a feature and the closing of such feature. Common sense says that one should aim at minimizing the average lead time. A low lead time means that the team is fast in turning the original idea into a solution.
Measuring the lead time
We recently computed the lead time of our Data backlog via a widget available in Azure DevOps. The figure below shows the result.
Each purple marker is a Feature that we completed and released in production. We have the last 6 months as horizontal axis, and the marker is placed on the completion date. The vertical position of the marker represents the lead time, i.e. the number of days that are between the creation and completion date of the feature. You can easily notice that in February something changed. The lead time started to increase. What happened on February then?
Playing Priority Poker
On February, we changed our feature prioritization session and adopted Priority Poker on Airfocus. We did not have a formal method before adopting priority pokers. Prioritization sessions were mostly based on the opinions of team members about the relevance and the value of each feature. When the backlog of items is large, it is not easy to keep in mind a decent ranking of features in terms of priority
The consequence was that we tended to give priority to the features that were created most recently because we felt that they were more urgent. You can see in the bottom-left part of the chart that we have quite a large number of purple markers that had a small lead time. The markers on the bottom represent feature that were created and were immediately taken under development.
This bias towards recent features made us miss more valuable features that were hidden down in the backlog. When we started using priority poker, we were able to compute a numeric score that summarizes the value of the feature by weighting the business value with the development effort. When new features come, we compute a score for them and add them to an overall ranking.
We now have a numerically ranked list of features that sorts our backlog. This ranking puts old and new features on the same page and cancels our bias towards recent features. As a result, we were finally able to give priority to features that were older. This explains why the curve is rising in the lead time chart.
Summing up
We are basically paying our debt of valuable feature that were lost down in the backlog. Furthermore, we noticed a second benefit around playing priority pokers. Our dev team feels involved and part of the decision process that orders our work. This feeling is probably the least measurable improvement but, at the same time, the improvement that makes us most proud.
Do you want to hear more about Flowe? Look at our open positions!
