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.
The wait is over... Portfolio for Jira Server and Data Center 3.0 is now officially here! Platform releases offer Atlassian an opportunity to shift our strategy, make bold predictions about t...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events