9

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?

  • 1
    Depends on the bug and the story... – HorusKol Jun 29 '16 at 9:42
  • what is your process for "accept the user story as done" – Ewan Jun 29 '16 at 10:01
17

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.

  • 1
    A phenopmenally articulate answer with some really interesting nuance (ISO 13485 etc). Your thinking is in line with my own thinking but I just wanted to bounce it off someone else. Thanks RubberDuck. – Venture2099 Jun 29 '16 at 11:02
  • You're welcome @Venture2099. I'm glad I could help. – RubberDuck Jun 29 '16 at 11:28
  • 3
    @Venture2099 Ironic that you were able to bounce your ideas off of RubberDuck and come up with a solution. ;) – krillgar Jun 29 '16 at 13:34
  • 1
    But then what do you do when regulatory starts burying you in CAPAs for your high defect count because you logged "defects" that never actually made it out of development? :) – Affe Jun 29 '16 at 18:49
  • 1
    @Affe you show them that they never made it into production, because you labeled them as such. – RubberDuck Jun 29 '16 at 18:59

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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