{"id":291,"date":"2009-07-12T18:15:47","date_gmt":"2009-07-12T17:15:47","guid":{"rendered":"http:\/\/www.dtsato.com\/blog\/?p=291"},"modified":"2009-07-14T21:58:31","modified_gmt":"2009-07-14T20:58:31","slug":"velocity-gone-wrong-3-used-as-a-performance-measure","status":"publish","type":"post","link":"http:\/\/www.dtsato.com\/blog\/2009\/07\/12\/velocity-gone-wrong-3-used-as-a-performance-measure\/","title":{"rendered":"Velocity gone wrong #3: Used as a performance measure"},"content":{"rendered":"<p>Continuing with the series, this time I want to highlight a very dangerous anti-pattern: using velocity as a performance metric. Before getting into the examples of how it applies to velocity, I want to first explain my view on metrics. I am in favour of metrics and coming up with interesting ways of displaying data (information visualization is a very interesting topic). However, the problem lies in the way that these metrics are used. There are two main types of metrics that I like to categorise as:<\/p>\n<ul>\n<li><strong>Diagnostics Metrics:<\/strong> these are informative measurements that the team uses to evaluate and improve it&#8217;s own process. The purpose of collecting them is to gain insight into where to improve, and to track whether the proposed improvements are taking effect. They are not associated to a particular individual or to how much value is being produced. They&#8217;re merely informative and should have a relatively short life-cycle. As soon as the process improves, another bottleneck will be identified and the team will propose new metrics to measure and improve that area.<\/li>\n<li><strong>Performance Metrics:<\/strong> these are measurements of how much value your process is delivering. These are the ones you should use to track your organisation&#8217;s performance, but they should be chosen very carefully. A good approach is to &#8220;measure up&#8221;. Value should be measured at the highest level possible, so that it doesn&#8217;t fall into one team&#8217;s (or individual&#8217;s) span of control. People tend to behave according to how they&#8217;re measured and if this metric is easy to game, it will be gamed. There should also be just a few of these metrics. An example of one such metric would be a <a href=\"http:\/\/en.wikipedia.org\/wiki\/Net_Promoter\">Net Promoter Score<\/a> (that measures how much your custumer is willing to recommend you to a friend) or some financial metric like <a href=\"http:\/\/en.wikipedia.org\/wiki\/Net_present_value\">Net Present Value<\/a> (read <a href=\"http:\/\/www.amazon.co.uk\/gp\/product\/0131407287?ie=UTF8&amp;tag=danisatospers-21&amp;linkCode=as2&amp;camp=1634&amp;creative=6738&amp;creativeASIN=0131407287\">Software By Numbers<\/a><img loading=\"lazy\" decoding=\"async\" style=\"border:none !important; margin:0px !important;\" src=\"http:\/\/www.assoc-amazon.co.uk\/e\/ir?t=danisatospers-21&amp;l=as2&amp;o=2&amp;a=0131407287\" border=\"0\" alt=\"\" width=\"1\" height=\"1\" \/> if this interests you). As you can see, these are very much outside of a team&#8217;s control and to be able to score high on them, they should try and do a good job (instead of gaming the numbers).<\/li>\n<\/ul>\n<p>Going back to velocity, a very common mistake is to use it as a performance metric instead of diagnostics. Velocity doesn&#8217;t satisfy my criteria for a good performance measure. Quite the opposite, it&#8217;s a very easy metric to game (as mentioned in my <a href=\"http:\/\/www.dtsato.com\/blog\/2009\/07\/04\/velocity-gone-wrong-2-making-up-points\/\">previous<\/a> <a href=\"http:\/\/www.dtsato.com\/blog\/2009\/07\/03\/velocity-gone-wrong-done-is-not-done\/\">posts<\/a>). When approached as a performance metric, it&#8217;s common to see things like:<\/p>\n<ul>\n<li><strong>Comparing velocity between teams:<\/strong> <em>&#8220;Why is Team A slower than Team B?&#8221;<\/em> Maybe because they estimate in different scales? Maybe their iteration length is different? Maybe the team composition is different? So many factors can influence velocity that it&#8217;s only useful to compare it within the same team, and even then just to identify trends. The absolute value doesn&#8217;t mean much.<\/li>\n<li><strong>Measuring individual velocity:<\/strong> as <a href=\"http:\/\/www.thekua.com\/atwork\/2009\/07\/be-careful-what-you-measure\/\">highlighted<\/a> by Pat, this is a VERY DANGEROUS use of velocity, and it can actually harm your process and discourage collaboration.<\/li>\n<li><strong>A push to always increase velocity:<\/strong> it&#8217;s common to have a lower velocity in the beginning of a project, and that it tends to increase after a number of iterations. Inspite of that, I&#8217;ve seen teams pushing themselves to improve it when they reach a natural limit (Who doesn&#8217;t want to go faster, right?). Velocity measures the capability of your team to deliver and, as such, tends to stabilise itself (if you have a stable process and the number is not being gamed). A <a href=\"http:\/\/en.wikipedia.org\/wiki\/Control_chart\">Control Chart<\/a> could help you visualise that. As noted by Deming, in a stable process, the way to improve is to change the process.<\/li>\n<\/ul>\n<p>It&#8217;s important to remember that velocity is a by-product of your current reality (your team, your processes, your tools). You can only improve your process once it&#8217;s stable and you know it&#8217;s current capacity. Velocity is just a health-check number that will tell your team&#8217;s capability. It will not tell you about how much value is being delivered or how fast you&#8217;re going. You can deliver a lot of points and make trade-offs on quality which, no matter how you measure it, will impact your ability to go fast in the long run. As uncle Bob <a href=\"http:\/\/www.artima.com\/weblogs\/viewpost.jsp?thread=51769\">says<\/a>:<\/p>\n<blockquote><p>&#8220;The way to go fast, is to go <em>well&#8221;<\/em><\/p><\/blockquote>\n<p>So let&#8217;s stop using velocity to measure performance and look at it as a diagnostic metric to improve our software delivery process.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Continuing with the series, this time I want to highlight a very dangerous anti-pattern: using velocity as a performance metric. Before getting into the examples of how it applies to velocity, I want to first explain my view on metrics. I am in favour of metrics and coming up with interesting ways of displaying data [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[134,139,22,42,138,48,137,90],"class_list":["post-291","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-anti-pattern","tag-capability","tag-diagnostics","tag-lean","tag-measure","tag-metrics","tag-performance","tag-velocity"],"_links":{"self":[{"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/posts\/291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/comments?post=291"}],"version-history":[{"count":11,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/posts\/291\/revisions"}],"predecessor-version":[{"id":302,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/posts\/291\/revisions\/302"}],"wp:attachment":[{"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/media?parent=291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/categories?post=291"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/tags?post=291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}