Don’t estimate bugs!


Don't ESTIMATE bugs!

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.

 Scrum anti-pattern

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.

Time matters

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.

My thoughts

I’m not discovering a cure for the cancer at the moment, but just reminding you well known fact:

Nine women can_t make a baby in a month.

Nine women can’t
a baby
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!


  1. mwyrodek · July 22, 2017

    I am literally against estimation at all. So don’t think I want to defend them but as you say bugs will happen. So they are ‘known unknown’ which means they can be estimated. Maybe not after finding them (unless they are so large that it has to happen) but during planning story.

    We know they are bugs we have statistical information how long typically per story is spent on bug fixes. So we can take it into story estimation.

    Anyway, that was me being a Tester and seeking holes in the analogy. Estimates are evil!

    See you on SEETEST I will be also speaking there.

    Liked by 1 person

    • mwyrodek · July 22, 2017

      After posting the previous comment I realized that I have formed my thought little incorrectly (basically I have reiterated your point from middle of article)

      So allow me to rephrase it: Estimation should be a self in proving if you estimate stories you have data how much over-optimistic they were in past. And you can use that data when planning next time (including bug fixes). It requires little preparation end arguing but after few sprint in a row when you are right they will start to take it into account.

      Anyway, I Still hate estimates.


  2. Pingback: Five Blogs – 25 July 2017 – 5blogs

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s