Why can't a defect object directly attach to a feature object?

[Legacy User]

I generally have difficulty treating defects (orphan/escape defects) in our backlog, iterations, etc. similarly to user stories in Rally.  One particular problem I have is I am unable to attach these "orphan" or "escape" defects in our backlog directly to a feature in the portfolio.  We are trying to avoid nesting too much, and Rally forces me to attach the defects to a placeholder user story, and then to a feature.  I would like to see this changed. 

[kamwi02]

Hello, that's a great idea! In Idea Manager, I found an entry for it at https://ideas.rallydev.com/ideas/D3454  If you'd like to vote on it there, it will help us prioritize the idea against others to make Agile Central as great as possible.

 

If you have any questions or need help getting into Idea Manager, just let me know.

 

#ideamanager

[afiliberto]

Hi there,

I don't believe this thread hasn't been answered yet. The question remains, why can't defects be attached to features directly? What were the design decisions not to allow this relationship (defects to features) ?

People in my company are asking the same questions.

Note: doing a quick search, I've found 3 other threads about this topic: 

• Link defect to feature | Rally Software (broadcom.com)
• map defect to feature | Rally Software (broadcom.com)
• Defects list per Feature(s) | Rally Software (broadcom.com)

[Mitch Goldman]

IMHO, I don't think it makes sense to do so.  A feature is a portfolio item, not a work item like a user story.  Defects are issues against a work item, not a portfolio item. If you have a defect that you decided not to fix but instead defer until a later date, then convert it to a user story under that (or another) feature. If you are going to deliver a user story without fixing an identified problem, then converting the defect to a user story will give you an audit trail to look back on when months or years later someone tries to figure out what happened there as the defect will show a resolution of "converted". We make a habit of noting the new US# in the closed/converted defect as well as noting the defect# in the new user story.

[afiliberto]

Thanks for sharing your view @Mitch Goldman.

How about a product owner who wants to make sure that all the critical defects linked to a feature are fixed before go-live?

How can the product owner have visibility of these defects if they can't be linked to the feature directly?

Having to create dummy stories or converting the defects to stories seems like an overhead.

[Tony Soares]

A scenario we have in our organization are for defects that are open during end-to-end testing, where a more holistic test takes place that encompasses multiple features.  This is usually done as a final pass in the Stage environment. These defects are not tied to a specific user story but more broad in nature, and may tie to functionality at a feature level.

We've been opening up these defects as standalone defects (not tied to User Stories) and monitoring them as they need to be fixed before a release to production.  Do you have any recommendations on how we could better handle this scenario - it may be that our test practices aren't as agile as they could be.

Thanks for any feedback.

------------------------------
Tony Soares
Release Train Engineer
UnitedHealthcare
PA
------------------------------

[Mitch Goldman]

We create a story for E2E testing and open defects against that.  That helps us see in one place where we are in remediating what was found. Again, anything that is deemed deferrable, gets converted to a US for later refinement and prioritization.

[Mitch Goldman]

Again, a defect is an open/known issue on a work item (user story).  If the PO decides that the team can defer working on that defect to a later date, but the story can be delivered without that fix, that defect should be converted to a user story and tracked accordingly (ex, new feature of deferred issues, tags, made a child of a parent story under the feature that will hold all remaining issues together, .... really anything that works for your org/POs). 

An issue does not have to be solely tracked as a defect, it can in some cases be a user story.  If you find an existing production bug, you wouldn't open a defect on it, because unless you have a catch-all production bug story to house defects, you wouldn't have a user story against which to parent that defect. If you're POs are concerned about tracking, then the type of item it is doesn't matter, it's more about organization.  They could prefix or suffix defect-originating stories with DEFECT or something like that to call it out and then filter a feature's stories on that word/phrase.  You could create a custom field for user stories to specify if this story was a defect or not and use that for sorting/filtering.  That would be a bit more process, but it can drive user views/reports easily.

One final point, I don't think that converting stories is creating "dummy stories".  If you opt not to fix a defect, that's valid. It's no longer a defect on open work and depending on the severity would become a production bug. It should be brought into the team's backlog like any other work and really should be a story at that point. Capturing this a user story is probably the best way to do this and it flows better in a later sprint than defect would. Rally gives you the ability to have it automatically convert it for you, so the effort is minimal. Also, when this work is finally brought into a sprint, if QA finds any issues with it, they can easily create a defect on this new US, which is something they cannot do if it is worked as a defect.

Again, just my 2 cents on how I would suggest this be handled. Every organization finds what works best for them based on the tool and what its structure allows.