Skip to main content

Time spent on investigating a bug that was not a bug after all

Last post 02:52 pm January 13, 2020 by René Gysenbergs
3 replies
11:23 am January 7, 2020

Hello, I am a scrum master and I have a question regarding adding bugs that turn out to be not bugs after all.

I have a case where a QA reported a bug and the developer spent time investigating the issue, it turned out that this was not a bug so, the QA decided to remove the bug (as they found out it was not a bug after all) but the developer spent time checking it.

How can we log the time spent by the developer? is removing the bug the right thing to do? or shall we keep it and keep the investigation task?


05:25 pm January 7, 2020

How can we log the time spent by the developer? is removing the bug the right thing to do? or shall we keep it and keep the investigation task?

What are you actually trying to achieve? My advice would be to focus on improving the team's understanding of what Done means.


07:27 pm January 7, 2020

Why do you need to log anything? Scrum isn't a time tracking tool. It is a tool to aid a team to understand and solve complex needs for a product. If your company requires time tracking then the people responsible for that requirement are the only ones that can answer this question.  

But if I were forced into this situation I'd consider this.  Did the QA and Developer spend time that leads to better understanding of the product?  Sounds like refinement to me. 


02:52 pm January 13, 2020

Hello Bayan,



There are three options:

1) The 'bug' is found during the development before the DoD had been reached:

    - The time of investigation is considered part of the complete development track of the user story

2) The 'bug' is found after the development had been closed, but within the same Sprint:

    - User story has been re-opened and the time of investigation is considered part of the complete development track

3) The 'bug' is found in an increment of a previous Sprint:

    - The 'bug' is opened in the Sprint as a new bug, time of investigation is added and bug should be closed as 'fixed'

    - Add in the bug description that it wasn't a 'bug'.



Just see that this becomes a learning experience between the developer and the tester AND not becomes a point of irritation overtime. We're all only people and people make mistakes.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.