I very recently had an article published in the Agile Record magazine in which I discussed how we could adapt the idea of a share chart to a scrum team to become a good indicator of how we are progressing over time. We would hope to see a generally increasing trend (not too fast – nearly level in fact). In that article I said I would be uploading a post here on howto adapt the Relative Strength Index measurement to scrum also.
To calculate an RSI value we must have 14 days worth of data. Each day our stock chart either has a gain or a loss in terms of burn. Firstly we calculate our initial average gain U0 and initial average loss D0 as:
U0 = total of gains over past 14 days/14 D0 = total of losses over past 14 days/14
Note that is we have a drop of -4 for a day then we have a loss of 4. Thus both U0 and D0 should be positive values. We then divide the average gain by the average loss to obtain a value R0. Our RSI value is then:
RSI0 = 100 – 100/(1+R0)
Everyday we recalculate our values on day n as RSIn = 100 – 100/(1+Rn) where Rn = Un/Dn and
Un = (13*Un-1 + daily gain)/14 and Dn = (13*Dn-1 + daily loss)/14
Our RSI values are between 1 and 100 and depending on this value indicate how our process is going. The aim of the RSIvalue is that it gives an indicator to us of where the direction of the burn may be going before it happens.
A value between 1 and 15 means that on average we are losing a large amount everyday and so something is going wrong in our scrum process that needs addressing. We could for example have massively underestimated on our workload or have an extenuating circumstance leading to mass loss of burn, but if we get to this point in our RSI, something needs to be done. A good suggestion is to call an emergency 1 hour timeboxed team meeting with the intent on finding out what the issue (if not immediately apparent is) and resolving it. Between 15 and 30 means that we are in dangerous territory of possibly dropping below zero and being underbought where some investment into the team in terms of resources will lead to a good increase in burn rate. For example we may be working on some difficult functionality in a new area and the extra investment of time into this will pay off dividends later when we can resue a more efficient method in our project.
Between 30 and 50 means we are just falling short of an even burn where we on average gain and lose the same amount (good days and bad days). This should be treated with some caution as it does mean we are losing more than gaining but generally can be similar to above with some bottleneck in resources temporarily.
Between 50 and 70 means that we are averaging just above even which is exactly the region we wish to be in. We are getting better at our process and just being a team. Be careful to look out for our burn rising too close to 70 as we will want to stay just above on the burn stakes meaning we have exactly the right amount of work.
Above 70 and below 85 is an area where we are burning very well and this should be carefully considered by the team. Are we estimating our cards correctly or have we found a clever way to speed up our development?(e.g. using LINQ as opposed to a million SQL queries, automating some code generation or testing). This should be watched carefully by the team but can be used as a good retrospective point for adjusting in a positive manner (we are over-performing, here is why, lets do that more and increase our velocity).
Above 85 is a big red danger zone indicating that on average we are burning at nearly double the rate. We have either not got enough work for the team, lied in estimation (finding all files containing the phrase “static TestMothod” and replacing it with “static TestMethod” is estimated as a 4 hour not 4 minute job – and if you disagree go learn about grep) or generally not been performing as required.
This is a very good system as it uses the previous average in its next calculation so takes in a larger scope of yesterday’s weather the further we take the calculation. It should be stressed that this is an indicator for the team (as is the burndown chart and my suggested scrum team share price chart) to see how they are doing. For me the essence of agile development processes are the focus on the team as the key part. Agile methodologies are for the development (including testing) team allowing them to do their obs (and for most developers at least this is their passion – I cannot talk for testers) in the best way possible for the team. Any team where this is adopted and it becomes an exercise in number crunching for a project manager is bound to lead to problems.