Life of a Defect

By | October 27, 2020

Hi there. There are many times where teams discuss what is or isn’t a defect. So, I put together a video sharing my thoughts of when a defect should be or should not be created. I’d love to hear your feedback! Below is the text of the video.

Thanks!

Rob

Life of a Defect

Hello! My name is D and I’m a defect. There’s so much confusion and different thoughts about who and what I am. So I’d like to clarify this for everyone!

Within the scrum framework, during a sprint, the development team works on a product backlog item, or PBI, to get it to done. Once the product owner wants to release the PBI, that functionality is put into production.

Users begin using the new functionality. If they find that the functionality is not working as expected, I’m created. I get placed into the product backlog as a new PBI, ordered by the product owner and then worked on the same way as any other PBI in the backlog. Sometimes if I’m critical enough, I get placed into the current sprint and get to done quickly and released to production.

That’s it! So, where’s the confusion I mentioned about at the start?

If teams for whatever reason are unable to release to production frequently, the confusion begins. After watching teams struggle with when to create me, I’ve come up with five main situations, so I’d like to go through them with you.

Situation 1 – For whatever reason, the work completed on the PBI does not deliver the desired scope. Some people try to create me. This isn’t a defect! That PBI should not be moved to done until it delivers the desired scope!

Situation 2 – Situation 2 is similar to 1. For whatever reason, the work completed on the PBI does not pass all of the acceptance criteria. Some people try to create me. This isn’t a defect! That PBI should not be moved to done until all the acceptance criteria passes!

Situation 3 – If a test case fails on the PBI, I don’t get created. This isn’t a defect! The team works to resolve the failed test case to ensure the functionality works or the PBI does not move to done.

Situation 4 – If new scope is uncovered while working on a PBI, I don’t get created. This isn’t a defect! A new PBI is created and placed in the backlog!
Scene 12: Situation 5 – This may be the trickiest one. If your team is not delivering to production frequently, you are in this realm of finding problems with your software in a non-production environment. Your done increment is done but not in production, and you find a problem. Is this a defect or not? End users haven’t seen the defect. Some think so, while others think not. As a defect, I feel that to resolve this grey area, move to being able to release to production as needed and you don’t have to worry about this!

Ultimately if a scrum team handles the 5 situations of 1. missing scope, 2. failed acceptance criteria, 3. failed test cases, 4. new scope, 5 deploying to prod less frequently, your team can focus on the implementing the idea of having 0 defects and frequent releasing to production!

Thanks for watching, please feel free to comment below or contact me at @RobReedJr

Leave a Reply

Your email address will not be published. Required fields are marked *