Do you consider a defect an actual defect if it occurs in Dev prior to the acceptance of the User Story as Done?

Question

A fully agile centric question.

If an exception, error, defect or bug occurs prior to the completion of a user story; do you log it is a bug or do simply consider part of the work required to make a user story done?

Answer 1

Working software over comprehensive documentation.

In general, I'd say that it just gets fixed and considered part of the work needed to complete the story. When you found the bug, you added a failing test to document it prior to fixing it, right? Right? Thats more than enough documentation for most use cases and doing anything more is useless overhead. (Obviously just my opinion, but I know many who would share it.)

However, you might have very good reasons to track this information anyway, in which case, you should log the bug. For example, we currently have a quality initiative where I work. We want to show that the time spent doing code reviews, unit testing our code, and a QA check are reducing the number of bugs that make it to production. So when we find a bug prior to release, we tag it with the stage of our process the bug was discovered in. Using this information, we've been able to show the business that this is time well invested.

Another reason you may want to track these pre-release bugs is if you need to meet ISO 13485:2003 specifications. When your software is used to manufacture medical devices, every code change needs to have a documented reason for changing. I'm not 100% sure that pre-release bugs need to be documented to meet this requirement, but my team didn't want to take that risk.

Another good reason to track the bug is to make the work visible. Let's say you're using a Kanban board. Dev finished a story and sends it over to QA (who sits right next to them, right? Right?). QA finds a bug in the story, logs the bug, and puts in on the board's "Urgent" lane (or simply the top of the backlog). Then it's very visible that this bug needs to be fixed in order for that story to be completed for this iteration. The QA documented the bug, so the next available developer can pull the bug, whether or not that was the dev who was working on that story. This maximizes the team's cohesion and flow, forcing the team to work as a team in order to meet their goals.

So, like all things in software, it depends. Do what works for your team. Don't have a need to log it? Great. Don't. Maximize the work not done. Have a need to keep track of these things? Fantastic! Then keep track of it.