A classic bug that has existed in the product increment since a previous sprint might be troublesome, but should it be fixed right now? Conversely, just because a feature is working as designed doesn’t mean the behavior is desirable.īy themselves, neither distinction is as helpful as we’d like but combining them a 2×2 matrix can guide our decision making: Not Working as Designed, Found within the Sprint However, a different distinction can be made to guide defect management: is the feature “not working as designed,” or is the feature “not designed as it should work?” The former is more like a classic bug: “When I click this button, nothing happens.” The latter is a function of perspective: “I’m expecting a different behavior than the story calls for.”īut that distinction can still leave us puzzled about what to do. And just because a defect is found while testing a story, that doesn’t always mean that it needs to be fixed right away, especially if there is disagreement about what the expected behavior should be. Not all defects are significant enough to need a task the developer might simply fix it as part of ongoing work. However, this approach gives less guidance than we might like. If the defect was created during a previous Sprint, it becomes a separate Product Backlog Item-one that may or may not be worked into the current sprint, depending on its severity.
If it is found “ during the Sprint”-that is, the defect relates to a story in the Sprint Backlog-the team makes it a task within the relevant story. An easy distinction to make has to do with when the defect is found.
0 kommentar(er)
