linking working item types, i.e. link a defect to another defect

[scott fawcett]

I know that you can link/connect/associate a Defect to a Story by simply adding the Defect to the Story.  But what about other types of links?  Specifically, I have 2 or 3 defects that are all related.  How do I link those so that a developer knows to address all of them when starting one.  Or other types of links, i.e. related to, child/parent, etc.  I've see these in all other apps I've used.  I'm fairly new to Rally.

[Sagi Gabay]

Hi Scott.

Defects are not a hierarchical object so you can't organize defects in a parent/child relationship.

You can organize defects in 'Defect Suites'. A Defect Suite can include many defects, so you can group them together this way. BUT.... a defect suite can also be added to an iteration and so you need to decide what is the actual purpose of organizing your defects together. If the purpose is to schedule them together as a 'package deal' to an iteration - then including in a defect suite seems appropriate. If your purpose of grouping them together is simply for an organizational reason, not a scheduling reason - then it's not too obvious whether you should organize them in suites. You can technically organize them in suites while not scheduling the suite to the iteration, hence scheduling the defects individually, but it can be confusing, unless you standardize this practice with your team and probably other teams.

If your challenge is how to locate certain defects then probably an easy enough practice is that you create a filter that locates them (such as by Owner, perhaps in combination with other fields), you can also save that as a View so that you can get back on that list with '1-click' .

I hope this helps. If not, please let us know your ask more specifically.

Thanks,
Sagi

[scott fawcett]

The main reason is to make sure we streamline our work as much as possible.  Here are some examples where I've used this feature in other apps, i.e. Jira:

• we're working on a new feature/user story where, when complete, could fix a couple bugs.  We'd like to link those so that they are all tested at the same time
• we have 4 bugs that are all related to a specific feature.  We'd like to link those so that we can easily navigate between them when discussing when to work on them...and provide both the developer and QA info that there are other related bugs that should be dealt with at the same time
• we have a bug that's dependent on another bug being fixed first.  In this case i've seen "dependent" as the link type.  This is especially important if we want both bugs fixed in the same sprint.

I'll read up some more on defect suite, as that may solve one of our scenarios.

[Niveditha (Nivi) Gadamchetty]

I agree with everything Sagi is saying here.

In my team, we use the Duplicates tab sometimes to tie together similar defects, so that we don't lose track of them.
So in your example, we would tie one defect to the story and then all the other defects would go into Duplicates of the first defect. 

It's not a perfect solution, but it is an understanding that our team has come to.

Regards,
Nivi

------------------------------
Project Coordinator
John Deere
Cedar Falls, Iowa
------------------------------

[Keith Jones]

Scott,

We have similar challenges, and decided to use the Feature hierarchy, grouping the user stories under a feature (in our case, grouped by functionality).

Additionally, we created a generic user story for each feature and that's where we store the one-off defects that may have been pulled out of a backlog as something to address whenever we touch that particular functionality.

------------------------------
- Keith Jones
- MCIC Vermont
------------------------------

[Karen Gwynn]

We have a similar situation, where we want to group together defects, mainly so when we do work on a specific area of the application, we can easily find any outstanding defects that might be addressed. What we've done is set up parent stories for defects: a user story that is part of a larger feature and that has the defects associated with that feature. I've named them all "Parent story for xyx defects" and keep those stories out of the backlog by assigning them to a bogus "release." When I look at items associated with a feature (which correlates basically with areas in our application), I can then see if there are any open defects to address (or that, happily, were addressed by "accident" when an enhancement was completed).