Do defects exist for scrum teams?
Defects exist for scrum teams. The difference under a scrum model is that we’re going to fully build product. What we mean by that is we’re going to elaborate the requirements, design them, develop them, test them, integrate them, document them, and have them approved. So, when we work on a requirement we’re going to work on it to completion. We’re then going to bring that to the customer representative, and under a scrum model that’s called the product owner. They’re going to work with it discretionarily. When the product owner accepts that requirement, down the road if there’s something that they don’t like about that requirement, that’s fine. What we normally say is, “Don’t go and label it a defect–don’t label it a bug” (which says to the development team you did something wrong, but they didn’t). Instead, go ahead and write a requirement that says, “We accepted this existing requirement as-is, but now we have better information–we want to have some changes to it.” Go ahead and write a user story for that, put it in the product backlog so that we can prioritize that work against our existing work.
So do defects exist? They do, but they often exist within the sprint itself where the team can correct it before it actually goes out to the marketplace. This is absolutely critical because it is exponentially cheaper to prevent a defect than it is to try to rip a defect out of a deployed system. Under a waterfall model, that’s mostly what you’re doing–ripping defects out of deployed systems.