A further chart provides more details. This chart shows the per-member churn, or the total number of lines of code added and deleted from files. From this chart, we can see that each week in which there were abnormally high build failures was accompanied by abnormally high churn rates. We can even see in each week which developer was responsible for the high level of churn.
From this investigation, we can see a co-variance between per-member churn rate and build failures. The next step is to determine what we would want to change about development in light of this information. For example, we could create an alert that helps us become aware of abnormally high churn levels and indicates that special care should be taken with the builds of the system because they are more failure-prone than normal. We might also do a root-cause analysis to determine if there are ways we can change development so that such churn values either do not occur, or if they occur, do not impact negatively on build failure levels.
Finally, notice the spike in churn at the very end of this interval, for the week of October 31? What do you think this will do to build failure rates?