Let me tell you my use case.
We have a software base being enhanced and fixed by several teams, each with its own JIRA project and backlog. The software is used by a series of customers that may ‘cherry-pick’ what bugs/enhancements (issues) they are interested in for their own releases. This is intrinsic to the nature of the software and can't be avoided.
So assume we have two teams, Team 1 and Team 2, each with three issues in their respective backlogs (1 to 3 for Team 1 and 4 to 6 for Team B). Now assume we have two customers, A and B, and let’s say customer A is interested in issues 1, 3, 5 and 6 while customer B is dying for issues 1, 2, 4 and 5. Notice how both customers want issues 1 and 5, while other issues are requested by one customer only.
(Please see the attached image for a sketch of this example)
How could we configure Portfolio so that there is a “Release for customer A” including issues 1, 3, 5 and 6 and another “Release for customer B” spanning issues 1, 2, 4 and 5, provided we can’t assign an issue to two different releases?
Ideas welcome! ^_^
I found the answer myself: the sentence "provided we can’t assign an issue to two different releases" is actually FALSE, Portfolio and JIRA allows to do that.
So so far so good.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.