SCRUM Productivity Metrics

Sharing a short white paper that I have prepared on individual productivity metrics in a SCRUM project: As Peter Drucker once said “What gets Measured, gets Managed”. It is an old management adage that is accurate even today. Unless we measure something we don't know if it is getting better or worse. You can't manage for improvement if you don't measure to see what is getting better and what isn't. In that pursuit this short write up lists some of the individual performance metrics that could be used in a SCRUM project to identify the kind of performance a team member is putting up and identify areas of improvement and areas where in he or she is performing well. Though it is a known fact that SCRUM in principle gives prominence to teams rather than individuals and sticks to the principle that “You stand as a team, You fall as a team”. But on the contrary if one needs to manage, he needs to know what the weak link in his team is or he should make sure that his team members are improving with every Sprint or he needs to know how he could manage his resources in the SCRUM team, as these individual performances would ultimately stack up to the team performance. Hence Metrics comes in as an inevitable way to achieve this. As in most cases the metrics discussed in this write up as well needs to be measured relatively, vis-à-vis the individual’s earlier performance and/or vis-à-vis overall team performance. Individual Performance Metrics The details of the individual metrics suggested in this write-up are mentioned below: 1. Earned Value (Story Points Completed in Sprint)/(Story Points Estimated for a Sprint) The Story Points committed by a resource in a Sprint would be known mostly by the Sprint Planning meeting and the Story Point completed in the Sprint would be known at the end of the Sprint in the Sprint Review meeting. 2. Efforts per Story Point (Total hours worked in current Sprint by a team member)/( Total Story Points completed in current Sprint by the team member) Ideally as a team member works on more and more Sprints, over a period of time his understanding of the product and the technology used should improve, which in turn means that the effort he used to complete a Story Point should see a declining trend over a period of time. This metric is an indication of the learning curve of the individual resource. 3. Actual Effort/IEH (Actual Effort Spent by the resource in this Sprint)/( Ideal Engineering Hours(IEH) of the resource in the current Sprint) This metric is indicative of the extent to which a resource is occupied. This metrics should ideally be used in conjunction with the earlier metrics. 4. Defects per Story Point (Total number of defects in a Sprint recorded against the stories worked by the team member)/(Total Story Points completed in the current Sprint by the team member) This one is more of an individual quality metrics than a productivity metrics. Pre-Requisites The measurement of the above four metrics requires SCRUM projects to record the Story Points assigned to each and ever user story or task. Recording the efforts won’t suffice as efforts assigned to a task are only indicative of the time required to complete that task and doesn’t take into consideration the complexity associated with the task. Also IEH for each team member should be recorded during the Sprint Planning meeting. Illustration This section tries to depict some examples of the ways these metrics could be interpreted and used in a SCRUM project. 1. Illustration of Earned Value Metric The below chart (Chart1) depicts the earned value of a resource across the 7 Sprints he has worked. Here X-axis indicates the Sprint number and Y axis indicates the Earned Value figures. As required he has shown gradual improvement in the Earned value. But then this chart stand alone doesn’t give enough information. Hence we plot Chart 2.

Chart 2 compares the progress of the same resources vis-à-vis the average earned value of the rest of the team. Such charts could be used to derive conclusions as to which resource is mainly responsible for bringing down the overall team’s performance, which could eventually be followed up by a detailed investigation to know the exact reasons and thereby the corrective actions. Say for e.g. is it that the resource is under skilled and requires training or has some motivational issues etc. Looking just at Chart 1 we could have concluded that this resource performed badly in Sprint-4. But then when we consider Chart 2 we realize that the entire team had a negative trend in Sprint-4, which helps us come to the right conclusion that in Sprint-4 it was not necessarily an issue related to this resource alone, but something pertaining to the entire team which brought down the EV. This could be because of unclear requirements, or due to some other dependency. 2. Illustration of Efforts per Story Point Metric Consider the table shown below (X-axis represents resource names, Y-axis represents the Effort per Story Point) which depicts the Story Points completed by each team member in a particular Sprint and the total effort the team member had spent in that Sprint. Now in the first look it might appear that the resource AR is better than PN since AR has completed more Story Points as against PN. But a look at Chart 3 clearly depicts that PN seems to be more efficient than AR, as PN takes lesser number of hours to complete a Story Point. Ideally owing to the learning curve. Resource Story Points Completed Actual Effort Spent Effort / Story Point BH 24 46 1.916667 PN 16 38 2.375 AR 18 48 2.666667 SP 10 20 2

Similarly we could also use this metric to plot ‘Effort per Story Point’ for a certain resource across multiple Sprints. This will shed light on whether the resource has shown improvement in his productivity across subsequent Sprints. (E.g. Chart 4). With reference to Chart 4 the resource has shown improvement across the release except in certain Sprints (E.g. Sprint-4) which if need be could be investigated as to what was wrong in Sprint-4, which could yet again help the SCRUM Master/ PM know if this resource is good at certain kind of tasks and not good at some others, or he needs some training in certain parts of the product which he worked during Sprint4 etc.