All About Agile | Agile Development Made Easy!

Metrics

Hi all. One area I have always struggled with over the years is metrics. Since doing agile development, Velocity has given me an indicative measure of output, but it's not really possible to use as a benchmark between teams, so it gives me no real sense of whether the output is good or bad, just whether it's better or worse than before, which admittedly is still very useful. We've also been using a metric we call 'reliability'. This is the number of story points delivered as a percentage of the number of points committed to in sprint planning. This gives us a reasonable gauge of how good the team is at delivering on their commitments. This is a major factor in stakeholder satisfaction because it measures how well we meet expectations, at least in terms of volume of work delivered. However it doesn't help at all to measure quality, either in terms of how well the software works or whether it's what the users really expected. This kind of qualitative measure has always been very tricky in software development I think and I've never quite managed to crack it.

I would be very interested to understand what other people have done with metrics and what you have found to be effective or ineffective, whether it relates to quality or any other aspect of software development?

Kelly.

▶ Reply to This

Replies to This Discussion

Permalink Reply by Priya on February 18, 2011 at 10:13

Hi Friends,

My organization is going to adopt Agile and I am asked to suggest what kind of metric can be collected with a sample of data and chart. Can someone help me???

Priya

▶ Reply

Permalink Reply by Manfred Lange on February 21, 2011 at 20:20

One metric I use for measuring quality is the defect arrival rate. Basically I count the number defects reported per time unit. I also track the "issue" arrival rate. As an issue I count everything that a customer has a problem with. Therefore the latter includes items that are not bugs as such (the software is working as defined). For example if a user has difficulties with a particular feature then this would count as an "issue" as well. It indicates an area of the product that requires attention and we then endeavor to improve that feature so the number of issues with it decreases.

Does this mean the arrival rate will go to zero? That would be nice but my hypothesis is that as the quality of the product incrementally increases so do the expectations. With bad quality people don't both reporting aesthetics or usability. All they want is a product that works. Once it works they want a product that provides more business value and - eventually - is also nice to look at.

In combination with the defect/issue arrival rate I also track the defect/issue resolution rate so that I have a metric that gives me an indication whether or not the backlog increases, decreases or stays the same.

If you combine defect arrival rate with an parameter that helps identifying the area of the product that is at fault (not from a implementation but from a feature perspective) then you also gain a tool that helps directing your QA efforts towards the areas that need it most.

I use other metrics but these are the ones I found extremely valuable in my experience.

▶ Reply

Permalink Reply by Priya on February 22, 2011 at 10:26

Thanks Lange, It will be helpful if you can list all the metrics such as project velocity etc. Thanks for your help.

▶ Reply

‹ Previous
1
2
3
Next ›