How have you structured your jira projects when developing a platform of shared components?
We have two main product lines and used to have a defect tracking + greenhopper project for each. Support, operations , program management created issues in the defect tracking project and the dev team handled implementation in the greenhopper project via sprints.
Now we are moving to having two "platforms" comprised of components of which we share some between them. How should we organize jira projects to support the following goals:
What I'm thinking of is this:
Two "platform" jira projects for defect tracking only. All customer requests and reported bugs begin here. In orbit around these we have a series of greenhopper projects. We have one greenhopper project for each component and we use release lifecycle or teams to determine how to draw the boundaries. The normal use cases would be:
Issue Originates At Platform Level
Issue Internal to Component Originates At Component Level and Resolved
If a problem was found then we'd create a platform bug and go through the Issue Originates At Platform Level case
Please let me know if you have had to deal with this situation, if you have any suggestions or if you see any pitfalls to this approach.
1 or 2 Kanban boards look like the answer here, did you give them a go?
You can distinguish by ranking, another option is to create an Out Of Scope Backlog or Out of scope label.
Hi Atlassian community, My name is Max and I work on the product integration team at Atlassian. I am pleased to announce the early access program for the Jira Cloud add-in for Outlook. This add-in...
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