3

We plan 2 week sprints with all tasks and bugs as much as we can. Every once in a while our QA Lead will assign the developers "bugs" mid-sprint for UI inconsistencies or non-emergency (or what he perceives as an emergency that actually isn't).

This is really frustrating to me, as my tasks of late are dealing with a new product about to be released and then I get a "bug" assigned to me about how the QA Lead doesn't like the layout of a registration form on a web app I haven't touched in who knows how long and I need to fix it right now.

I guess that my question is actually this: What is the "official" definition of a bug, what kinds of bugs are appropriate to interrupt planned tasks to fix and what can I push back on?

Improve this question

4 Answers 4

Reset to default
5

There are many definitions of what is a bug and what not. For instance, Brian Kernighan once said:

Without specification, there are no bugs—only surprises.

However, I really like Zero-Bug Software Development, which might be interesting for you. According to this philosophy, issues are classified as follows:

  • Critical issues
  • Bugs
  • Features
  • Improvements

Zero-Bug Software Development clearly defines when to stop what you are currently doing:

enter image description here

The main message here is:

If you can live with it, it's not a bug — it's an improvement.

Have a look at this blog post by Sam Hatoum. It is a 10 minute read and may help you to introduce some guidelines on how to deal with "bugs".

Improve this answer
3

The whole idea of Agile is that the quality is built in. The developers and testers should be working together as a team to do so. From you question I'm sensing annoyance with the tester, who is just doing their job. What can you do to improve the working relationship?

Improve this answer
2

If you have a product owner, the product owner should be prioritizing the bugs. If that's not an option, you might want to make a rule that in the sprint, new work is completed first, then bugs. If the bug needs to be done before that, it can be specified in the daily sprint.

If you're getting tapped on the shoulder for silly stuff, designate someone who is relatively client-facing to be the 'stakeholder' and tell the QA lead that all 'emergencies' have to go through her approval first.

Improve this answer
1
  • so looking back at your question - I'm getting the sense that both you and the QA lead are stretched too thin. Why is the QA lead suddenly very concerned with something that hasn't been touched in a while? Why are they putting you on it when you haven't touched it in a while? They must have a backlog of work, and it sounds like you are covering too many apps. Just MHO.
    – LeLetter
    Commented Feb 2, 2018 at 23:13
0

Why is your QA lead assigning bugs/injecting work into a sprint? Something sounds broken in your agile process.

If you're properly estimating and what not, when you inject new work, you should be pulling out other work from the sprint.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.