RELATED IDEAS
This idea has been merged into another idea. To comment or vote on this idea, please visit A-I-14573 Manual Sending of Requirements to integrated development tool.
Allow children of integrated items to remain not integrated until ready
Merged
I integrate our epics (master features), features, and PBIs (requirements) with DevOps (previously known as TFS). Often, I want to insert a new PBI (requirement) but I don't want it to be pushed to DevOps until it's fully built-out and ready for the DevOps team. Since the parent item has an integration connection, the new child gets pushed even though I'm not ready for that to happen. I end up with half-baked PBIs in the development backlog. A work around, I understand, could include requiring ALL outgoing changes to be approved, but that would be overkill and would be worse than the alternative. Is there a way to prohibit integration of new child items of parent items that have already been integrated?
2
MERGED
Wait before creating new integrations of Requirements
Looking for a way to best utilize the ability to choose the type of item to be created in the integrated system.
My integration to VSTS (now DevOps) allows me to choose to send an Aha! requirement to VSTS as either a story or a bug. If the featur...
0
Future consideration
To add a bit more context here, I'm trying to solve what I think is a bigger challenge. As a product manager, I'm trying to create new features, which have -- or will have -- work items that may be assigned to different teams, including internal and external and one team may do design while the other does development. My design team uses DevOps while my vendor uses Jira. One approach would be to create a master feature (epic) with one feature for design (Jira) and another feature for development (DevOps). For this to work, I would have to ensure that master features are not included in my integration definitions, lest they get pushed to the corresponding system.
Following up on my earlier comment, I think the integrations must include a hierarchy (feature + pbi), otherwise the items won't be related in the target system.
That is an interesting idea. I think the issue you will run into is that you will not get the parent/child relationship set in DevOps since there would be no "Links to" mappings in your Aha! integrations.
I wonder if I could work around this challenge by changing the integration definition so that it doesn't include the entire product hierarchy (master feature > feature > requirement). What if each level had it's own integration? It would mean pushing each item separately but it seems like I would have more control. I'll have to test to see if it would create the parent/child items in DevOps, although I tend to think it may not.