Scrum Sucks! Part 5 – Measuring up

Measure first

Before making any changes, first you must know where you currently stand. In business, feelings don’t matter, Money is what matters; for a new process to be the correct one for your company that process must provide a higher earning potential than the current process.

Many metrics for business success exist. What we must do is find the metrics that best measure your companies earning strategy. I don’t know the way your company works so, as much as I would like to, I can’t deliver specific actionable details about how to setup the correct metrics for the success of your projects. I can, however, provide general suggestion that should help most companies.

Time to Production

The first metric is Time to Production. This metric is measured by how long it takes a project, requirement, or bug to go from concept to production. The word concept can be a bit vague, so instead measure this from the time the project, requirement, or bug are scheduled to be worked on. The end point for the Time to Production metric is simple. You stop counting the seconds when the project, require, or bug are in production and being used.


The second metric I would suggest is one of quality. The Bug Count metric is simple, just count the number of bug per production project overtime and then divide by time. For instance, if a project had 24 reported bugs over the course of 6 months it could be calculated as that project having a bug rate of 4 bugs per month. Generally, more bugs are reported shortly after a project is released so it is best to start counting from release and stop counting when the bug count has died off or stabilized.

Cost of Failure

The last metric that I’m going to suggest is probably the easiest to calculate. It is the Cost of Failure metric. This one is fairly simple, find the last several projects that have been deemed a failure. Two common ways a project fails is by dying on the vine, that is that the project never makes it to production, and failing to meet project goals. It should be relatively easy to find a few projects that died on the vine. It will likely be more difficult to find the projects that failed in production. In my experience, companies either aren’t making project goals or aren’t sharing the results of a projects release and it’s success or failure in meeting those goals. Hopefully you are a business person reading this and will have more luck than I have in getting those details. Back to the metric, this metric is one of money. We want to find out how much money was spent on these project, how much time they took to release or develop, how much money they were predicted to generate, and how much money they actually generated. Sometimes a failed project isn’t a total waste and does generate some revenue, just not as much as the company had expected.

Now, we may begin

Now that we have a few metrics, and a time scale for those metrics, we should be able to enact a new process, or part of one, and start measuring results against the same timescale. That’s right, we need to compare apples to apples so our test phase for each metric must be as long as it took to make the measurements. We can’t skimp out on doing proper and thorough measurements in order to speed things up though, that would be a recipe for disaster. In the next post I will give my suggestions for how requirements should be thought about and recorded. As always, I hope this article was helpful and thanks for taking the time to read it.

Clayton has been programming professionally since 2005 doing mostly web development with an emphasis on JavaScript and C#. He has a focus Software Craftsmanship and is a signatory of both the Agile Manifesto and the Software Craftsmanship manifesto. He believes that through short iterations and the careful gathering of requirements that we can deliver the highest quality and the most value in the shortest time. He enjoys learning and encouraging other to continuously improve themselves.

Please Consider Sharing This Post: