headbanner

Menu:

nigel-1

Quick Notes:

August 8th, 2009:
I've moved to Melbourne, Oz. I've sold my soul to consultancy. I'm still writing code. :-)

Read more...

About Nigel

Nigel is a senior consultant at ThoughtWorks, passionate about pretty much everything, and quite insane.

Previous Posts

- When you love what you do, its not work.

- Some IE6 users are just irrational.

- Forget browser wars, bring on the OS wars.

- Are you asking yourself the right questions?

- Things every software developer should know.

- Self-refine your product idea.

- Is Miro the future of the browser?

- Hicks and Fitts for better software

- The power of content pull: Ubiquity and Deckkr

- Head south to start your company

Archives

- July 2007
- August 2007
- September 2007
- October 2007
- November 2007
- September 2008
- January 2009
- July 2009
- August 2009
- September 2009

My choice of links
worth visiting

Check out

- BookEazy
- Intermission
- Sukshma
- Lipikaar
- Badal's Blog

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]

Hi. You've reached Nigel.in

What you have landed on, possibly inadvertently, is the website of a certain curious character a.k.a Nigel Fernandes

The aim of this page was to serve as a landing point for those of you who want to know a little more about me. The links on the right and left will take you deeper my world, or possibly on to different exciting things.

Its a big web out there and this is just one more street for you to saunter down. I hope you like it.

Close this.

My Photo
Name:
Location: Panjim, Goa, India

Crazy, dancing, programming, Goan.. I'm a computer geek and proud to be one. I program in Java, Ruby and .Net, PHP, Javascript. A lot of my recent work has been about CSS and UI design practices for large scale websites and Agile teams. I still while away hours dreaming up a web startup.

 

Smelling Bugs

Thursday, August 13, 2009

A few months ago, we learnt that our team had the highest bug count per point delivered as compared to any other team. Since the program of work is composed of several teams all working on the same code base, this was a point of obvious concern.

At first we tried throwing more QA's and more QA related process at it. Seemed logical but did not help much. In fact intense QA and QA process meant that story cycle time went up.

Then we started analyzing the bugs, and found fairly distinct trends based on the nature of the bug report.

We had a higher percentage of bugs caused by :
* Implementation defects.
* High levels of customer feedback coming in as bugs from UAT.
* The customer expecting more than the story scope.

Our actions:
* Return to core XP practices. Much more focus on pairing and pair rotation.
* Spend more time on story analysis. Get the programmers to pair with BA's on story definition.
* Tightened story acceptance criteria.

The results are trickling in now. Looks like we got our actions right.

Lesson: Pay attention to the nature of your bugs, not just the bug count.

Labels: , ,


Comments:
Yeah, i had similar feelings when they were trying to standardize on defect density at my last job. I had a hard time convincing them that it would probably be more useful to track the number of phases a defect leaked through instead. (It was a fairly waterfall shop).
Sometimes people are just too focussed on the numbers and don't want to see what they mean.
 
Thinking about the phase of the bug is interesting.

My take is that the exact phases through which 'a' bug slipped through is not very relevant.

I do agree there is value in analyzing the trends in the phase of leak through.
 
Post a Comment

Subscribe to Post Comments [Atom]





<< Home