Story Points at Coco Beach bar

Consider you asking a waiter how long it takes to deliver the meal and all he says is: "Can't tell you that, but I can tell you how complex it is to prepare". That's what story points are about. I already wrote about story points in the last post but copied a snippet to this cartoon.

Although story points have nothing to do with scrum (invented by Mountain Goat Software), many companies use these to estimate their tasks. Story Points are a bit special because they don't tell you anything about how long a task takes, but rather how complex a task may be to complete. In theory, a task can be very trivial and still take longer because it may invole a lot of monotonous activity to complete the task. On the other hand, a complex task can be completed within an hour or day depending on the skill of the one who is implementing it.

Although I have worked with Story Points for the past 10 years, I am still swinging between two different mindsets. I still can't decide if it is a cool tool or just a buzzword. The paradox of this measurement is the fact that on one hand you don't measure how long you have for a task, but you still do it indirectly because you take these SP numbers to fill the sprint. This is per se exactly the same as if I measured the hours I have for a task, because we fill the sprint only with a limited number of hours/days available. But, story points help you understand much faster when a task gets too complex. Since you are using fibonacci numbers, you get alerted right away if you have a task estimated higher than 8. There is no 9, no 10, the next number is 13. This huge jump is a great warning sign and leads you to rethink the size of the story.

Birds love BUGS

Here are the stats. I raised 2500 bugs in 12 years, then moved to a company where I raised a thousand bugs in only 19 months.
Presuming that a typical year has 252 working days, this gives me rate of 2.5 bugs per day or 12 per week (compared to an average 0.8 per day or 4 per week during the last 12 years).

That means the rate of identified defects has increased by the factor of 3.

What do these numbers tell about me or the software-under-test, or the company and what does it tell about the developers who introduce these bugs?
Do these numbers really have any meaning at all? Are we allowed to draw a conlusion based on these numbers without having the context? We don't know which of these bugs were high priority, which ones weren't. We don't know which bugs are duplicated, false alarm and which of those look rather like they should have raised as a change request.
We also don't know what is the philosophy in the team. Do we raise any anomaly we see or do we first talk to developers and fix it together before the issues make it into a bug reporting system. Do we know how many developers are working in the team? How many of them work really 100% in the team or less, sporadically, etc...Also, does management measure the team by the number of bugs introduced, detected, solved or completed user-stories, etc.? May the high number of identified issues be a direct effect of better tester training or are the developers struggling with impediments they can/cannot be held responsible for and these bugs are just a logical consequence of these impediments? Are there developers who introduce more bugs than others?

As is with these numbers, they are important, but they serve only as a basis for further investigation. It's too tempting to use these numbers as is and then draw one's one conclusions without questioning the numbers.