Currently the way defects are implemented within V1, they are good for defects found in production. As defects they make it into the backlog and get worked in sprints.
Bugs found while QA work is performed for an existing story in a sprint don't lend themselves to become V1 defects. I want to be able to contain them and the work they're causing within the feature story. As dev (vs. prod) defects they should also not dilute my defect reporting.
We are currently adding V1 issues for these (type dev defect), but that's now a separate list from the sprint backlog and they're not explicitly associated with BLIs or even a sprint.
Just saw on Rally today that they have the equivalent of tasks, tests AND defects under a BLI. That makes a lot of sense. I'd love for V1 to have similar functionality.

Comments

  • Agreed that these are two concepts that should be handled separately. I'll explain how we recommend differentiating...

    If a feature in development is found to not work correctly, it should cause an acceptance test to fail. That may generate a new task to fix the failing test(s). In general, we'd consider this an unfinished feature rather than a separate defect, as all work required to deliver the working feature should be grouped together under the feature as you point out. It is possible to currently to differentiate originally planned work from rework/fix tasks through the Task Type designation. We recommend creating a defect only in cases if a deficiency is discovered after the story has been accepted by the customer and closed out. This approach keeps true defects wholly separate from normal story delivery activity.

  • Maybe it would help to have a customizable type of children for stories. So you could have a standard of task and test but you could also have additional custom types like "dev defect" or "automation/unit test".
    In fact this could be helpful to a lot of other teams probably.

  • At the very least, the integration with something like JIRA could be improved to add things like:
    - Report JIRA defect from v1
    - Report JIRA defects related to a story in V1

  • Mark, in addition to using "Issues" we also have been adding "fix it" tasks under the respective story to track the work of dev defects. This just won't allow for some kind of view or report to show all dev defects found within a sprint (some teams started dropping those into Bugzilla in addition to adding tasks). Also, please note that not all teams are using tests/acceptance criteria for a number of reasons.

  • While I understand your design, I do not think it aligns realistically with how most development shops work. in the last few software companies I have worked in there are typically 2 categories of "defects" 1 - issues found in production where functions are not working as intended or not working as designed. 2 - "In sprint or In release" defects. I have yet to work in an org that uses issues or even tasks for in sprint type defects. this process is usually driven by the QA org and they have very specific requirements - especially when it comes to metrics. therefore, this design is not usable to us, especially as we are using Jira to track defects.

  • Definitely would be a great feature to be added to V1 enhancements list.

    As a work around we added a Defect Type of "Sprint" for Defect and added a specific color "Dot" so it is visible in the team room story board. It works well from the perspective of separating them out from planned production defects.

    Thanks.

  • I just started using v1 with a new team. I worked with TFS before. It was so comfortable to be able to open bugs directly for the user story you are testing. I think Rene R. had a great idea over a year ago which can make our lives easier. Maybe backlog items "Defects" should be defects found in production and added into the backlog and get worked in sprints. But Bugs can be added to the user story that is already in process?

    Very Respectfully!

  • Agreed. Wonderful idea to add an new V1 Child "Asset" called "Bug". Very similar like "Tasks" and "Tests" that is always associated with a Story or Defect. Over an year ago Kathy T. said that I also agree that none of the software organizations I worked in the past use tasks or issues for in sprint bugs.

  • It makes absolute sense that Defects are first used once the related Work Item has reached your Definition of Done, and been delivered to the customer.

    Given this, it does not make sense that there is no Product Owner field on defects, so that the PO can find and prioritize their defects alongside their Backlog Items.