Yesterday, I came across yet another “typical” conversation with a “senior management” who is in charge of multiple projects in an organization. He said that he wanted to compare defects per story point of various teams under his portfolio. He said that as a centre head he wanted to know how is each team doing with respect to quality of software being delivered.
Well, I asked him, if story points themselves are not comparable across teams, so then, how can defects per story point (aka defect density) be comparable? And he picked up that point and said, that is why he hates story points! Because it doesn’t offer any comparative view, which he needs as a “senior management”.
Well, that’s interesting. Let’s assume for time being that story points can be comparable between two teams. Also, assume that your data shows trend that team A has 10 defects per SP and team B has 25 defects per SP. Now what happens?
Team B starts getting beaten up. Poor manager of team B goes back to “senior management” and says – you know what our application is much more complex than theirs. We have many junior resources than theirs, our requirements are very unstable than theirs, we have inherited an existing code which is very brittle and complex to understand, blah….blah….blah….
Team B manager is accepting defect density figure but also reasoning out that. And nothing wrong. Basically he is telling “senior management” that you are comparing mango with an orange and telling that orange isn’t as sweet as mango, in spite of being orange in colour! 🙂
We all must have had these kind of discussions, either with our managers or with our teams (depending on which side you were on :-)). What happens at end of any such discussions?
“senior management” finally says – “okay…I hear you. So what can
your team do to improve defect density from X to Y defects per SP? (assuming Y is less than X 🙂 ) Can your team show an improvement in few sprints from now?”
So, at the end of the day – where did the discussion end up? Basically, expecting each team to show an improvement from wherever they are today. In fact it also should have opened “senior management’s” eyes that 10 defects per SP for team A may not necessarily be a good number 🙂
Well then, what else are agilists telling us? Basically the same thing!
Don’t compare two teams – each team is unique – but rather focus on ensuring that each team on its own is showing improvements every few sprints. And now if all your teams show improvements, you as an entire business unit also have improved!
So…think again – does comparison across teams really help? 🙂
– चिंगुडे
Nice read. This piece of info re-iterates that comparing two teams in an agile set up just doesn’t serve the purpose. Team should be compared with itself (from the past) as far velocity and defect density goes. Team improvement should be the focus.
Good article. Gave me some ideas: )
Hi Sachin,
Very nice article. This is going help me in future. Thanks for sharing.
Thanks,
Sham