Questions & Answers
Get your Rally questions answered.
Question
Splitting Defects
Question posted Jan 26 by David Morsberger , tagged Defect Management, Planning, Scheduling, Status Tracking
2929 Views, 3 Comments
Title:
Splitting Defects
Summary:
What is the best way to handle a defect that it is decided by the team that it will take more then one iteration to resolve?
It appears that you cannot create children defects. We have discussed assigning the defect to the iteration we plan on completing it in but we see two issues: 1) the hours worked are not in the current iteration reports and 2) the second iteration is not final until we have completed iteration planning.
We looked at converting it to a story but from a purist perspective it is a defect against a delivered product and does not represent any new features. In addition, the user who wrote the original defect loses their ability to see the status of their defect.
Thanks,
Dave
Comments
Hi Dave,
While I don't have a "rule" for you to follow with these types of Defects, one suggestion I have is to treat them like unfinished User Stories and copy the Defects for scheduling into the future Iterations. There are a couple of posts about copying User Stories here and here.
This will allow the hours worked on the Defect in the current Iteration to be captured and will also allow for the Defect to be reprioritized in the next Iteration.
Hope this helps.
Michael
Reply to this Comment
One other note - you could also schedule a user story to spike the fix for the defect and then once you know more about what the fix is, schedule the defect and complete the fix.
Reply to this Comment
Dave,
You can also use the 'Duplicates' entry on the Defects you are copying to be able to trace the history of your copied Defect. This can be accessed by clicking on the Defect to access the detail page. The 'Duplicates' link will be in the left hand column.
Michael
Reply to this Comment