{"id":5091,"date":"2016-02-11T11:02:47","date_gmt":"2016-02-11T13:02:47","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=5091"},"modified":"2016-08-18T16:16:04","modified_gmt":"2016-08-18T19:16:04","slug":"why-we-love-metrics-learning-with-lead-time","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2016\/02\/why-we-love-metrics-learning-with-lead-time\/","title":{"rendered":"Why we love metrics? Learning with Lead time"},"content":{"rendered":"

Every time I think about indicators and metrics I remember a phrase from H. James Harrington<\/a> that says:<\/p>\n

\n \u201cMeasurement is the first step that leads to control and eventually to improvement. If you can\u2019t measure something, you can\u2019t understand it. If you can’t get it, you can\u2019t control it. If you can\u2019t control it, you can\u2019t improve it.\u201d\n<\/p><\/blockquote>\n

Just to clarify, as an Agilist, I understand “control” as the ability of the team to handle and formulate tools that bring self-management to the environment, instead of a culture of command-control.<\/p>\n

Since I started working on software development, I have seen metrics from two different points of view:<\/p>\n

    \n
  1. In the “dark side of the force”, metrics could be applied as a tool to see the team as a number and the only reason to collect them is to demand answers from people and create hazardous conflicts. Examples of this type of metrics are Unit Tests written, Individual Velocity, etc. (take a look at “How To Not Destroy your Agile Team with Metrics”<\/a>). <\/li>\n
  2. In the other side of the “force”, metrics could promote actions of continuous improvement and bring visibility to the team.<\/li>\n<\/ol>\n

    At Plataformatec, we use metrics to understand how we can make things better based on data, as an exercise of continuous improvement.<\/p>\n

    This blog post is the first of a series where I will share some metrics and charts that we have been collecting, and how we are using them in our projects.<\/p>\n

    Let’s talk about Lead time<\/h2>\n

    Quoting Wikipedia<\/a>, it is possible to define Lead Time as the latency between the initiation and execution of a process. For example, the Lead time between the placement of an order and delivery of a new car from a manufacturer may be anywhere from 2 weeks to 6 months. In the industrial goods sector, Lead time reduction is an important part of lean manufacturing.<\/p>\n

    In the software development context, we consider Lead time as the number of days between the beginning and the end of an issue (e.g., user story). One important definition to measure Lead time is to establish the done criteria. In some teams, “done” could mean a user story released to production, but for others could be the code merged into the master branch.<\/p>\n

    Frequently, we interpret the Lead time charts to answer questions like:<\/p>\n