Hello from abroad!
It seems, that when I am far away from home – I have more time for writing 🙂
Bunch of thoughts for today were a base for presentation, which I am preparing for SeeTest in Sofia. I have an honor to be a speaker at this well – known testing conference – it excites me a lot. I would also like to encourage you all to come, discuss, disagree or simply say “Hi!”. Looking forward to it!
The other day I came across this fantastic article about estimating bugs, written by Bob Hartman . He says: “I tell people in my classes I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it!”.
I like the idea of Infinite bugs, because, especially when you are in a project-hurry, all bug fixes seem to least forever.
To be honest, this is the definition I was looking for a long time. I am not sure if you have similar experiences in your projects, but each time in one of mines pressure appears – the pattern is quite predictable.
PM pushes -> developers try to declare (or predict using black magic) how much time do they need to provide fix.
Let’s state it clear – saying anything like we’ll knock out X bugs this iteration or I’ll fix it today – that is a lie anyway.
When we are clear about that, let’s try to focus on some Agile theory.
According to Scrum Alliance – estimating or sizing bugs is an Agile anti-pattern. Scrum is such a lightweight way of producing software that things just happen 🙂 We should not interrupt, limit ourselves, state clear deadlines.
On the other hand, when we are focused on quality, but driven by rush – bugs appear.
In addition, they emerge in most unexpected situations. In this case – Agile teams should deal with the problem – fix bugs, but do it within some realistic time frames.
The cleanest way is to add the bug into the current sprint, without sizing it.The context if fresh, so the fixing costs should be low. It’s cheaper and more efficient.
In a contrary – this will (for sure) lower the velocity and reflect the remaining bug-free stories. What is, in my opinion, important – the process should be always a decision of development team – not a PO, PM, manager or whoever is standing above your head and repeating “Is it done yet?”.
The other option of dealing with bugs and keeping the product in a good shape is to plan separated bug-fixing sprint but instead of scrum – run int in Kanban manner.
Whatever you choose – plan and fix – in a most suitable way.
What I wanted to highlight – is not estimating bugs itself – but schedule some time for fixing them.
At the beginning. In each sprint. Each iteration.
The truth is, that development tent to be way too optimistic when scheduling time of their work.
It is not matter of good or bad will, but simply focusing on own tasks.
The problem is, that each software project is not just a pure development.
Apart from writing and testing the code, usually it consists of (at least): setting up the environment, failing environment, meetings, discussions. Altogether it ‘steal’ the time. Ironically, it is THE TIME, we want to save.
When our fixed deadline approaches – the pressure rises. The more pressure there is – the more bugs appear. The more bugs appear – the less time for new lines of good code. And here we are. Chasing our own tail.
I’m not discovering a cure for the cancer at the moment, but just reminding you well known fact:
Nine women can’t
in a month.
When you add more developers to the project (because you are in a hurry) it won’t help. Either you are a tester or a developer – try to face it:
there are bugs
you’ll have to fix them eventually,
so be prepared 🙂
Schedule time for them at the beginning of the project to avoid the hurry.
Win – Win , isn’t it?
As usual, in case of any comments, ideas (whatever you have in mind) – comment down below or chase me on Twitter.
Have a nice weekend!