4635RE: [scrumdevelopment] SCRUM performance measurements
- Sep 27, 2004Thanks - with metrics you have to be very clear what you are actually measuring.
It should, of course, not be surprising that Scrum would decrease interuptions and
increase focus, but it is great to have a real measure of that. Still, in an endeavor
as complex as software development, the reason for a change in a metric is never
completely clear. For example, a large part of the improvement in this particular
metric may just be that the more flexible task definitions in a sprint makes it possible
to classify activities as being on task that were not considered on task under the
previous planning regiment, which was likely to be more detailed and less flexible.
From: Schiel James - SHS Malvern [mailto:james.schiel@...]
Sent: Mon 9/27/2004 6:52 AM
Subject: RE: [scrumdevelopment] SCRUM performance measurements
You can't -- I used data gathered through our project management software to determine the values before and after the Sprints began. So, while we weren't collecting the metric prior to Scrum per se, we did have access to the numbers we needed to determine the values back into 2003.
As for your second question -- I should clarify -- the metric itself (actual time vs. estimated time) is a measure of how many hours of effort each week are posted against the project's tasks as compared to the number of hours that were expected to be posted based on the schedule (whether those tasks are part of a Sprint Backlog or not is not relevant). For example, if I have tasks this week that I'm supposed to log 30 hours against and I log 25 hours instead, I've only worked 83% (25 divided by 30). For whatever reason, I didn't log all thirty -- this might be the result of unplanned sick time but, more importantly, it may be a result of unplanned activity that you really don't want your developers getting involved in.
One thing to note here is the difference in how you plan estimated hours. Before Scrum, when we planned out the task schedule for each iteration, a developer might have 34 hours one week, 21 hours the next week, 28 hours the week after, and so on. When we started Scrum and planned our a Sprint, we simply take the number of hours that a developer is allocated to the project (in most cases, this is 30 hours -- leaving 10 hours for education, emails, non-project group meetings, etc.). As an aside, if the measurements that I'm seeing hold up, we'll probably increase our allocations to 32 hours per week soon and see what happens.
In my group (as with many others), we provide third level support for everything that we write. Therefore, we get continual pressure to provide assistance to our support group as well as other development groups using our tools and components. That pressure, not properly controlled or monitored, results in a wearing down of your developers actual allocations to your projects because those developers begin responding to every call and interruption as if it was more important than their project (which it might be, but there's no opportunity to check before the time is lost).
One of the reasons we started using Scrum was that the ongoing and continual collaboration and accountability was seen as a way to encourage the developers on our project teams to focus more on the development tasks and leave the support to the small team of developers set aside each month to respond to support issues. As we began running Sprints, our actual vs. estimated time immediately began to climb. In a number of cases during the Sprint we just finished, actual vs. estimated climbed over 100% (which doesn't necessarily indicate overtime -- although some was spent -- it actually means that developers were closing in on putting all eight hours a day into the project rather than responding to every interruption that came by).
Now, I should be clear about something else too -- whether a developer achieves 90% of their estimated hours or 110%, this metric, by itself, does not mean that everything's going perfectly. There's still the matter of whether or not your developer spent eight hours on a three hour task. To untangle this issue, you have to turn to Earned Value reporting and/or the Sprint Burndown chart to see where you're going.
However, as a indicator of how well Scrum is keeping your developers focused on the project and not continually task-switching from one interruption to another, the actual vs. estimated hours per week works pretty well.
This message and any included attachments are from Siemens Medical Solutions
USA, Inc. and are intended only for the addressee(s).
The information contained herein may include trade secrets or privileged or
otherwise confidential information. Unauthorized review, forwarding, printing,
copying, distributing, or using such information is strictly prohibited and may
be unlawful. If you received this message in error, or have reason to believe
you are not authorized to receive it, please promptly delete this message and
notify the sender by e-mail with a copy to Central.SecurityOffice@...
- << Previous post in topic Next post in topic >>