I have been trying to crack JIRA to be able to organize my small team's work over multiple projects, and I am having a terrible time doing so. Here is a bit of context.
We have 2 teams:
The core team develops core features often requested by implementation projects. The criteria is if that feature request can be used by other implementations, it is part of core. For example, sorting a list is a core feature that can be used by multiple, different app implementations, where as something that is implementation specific would not be done in core.
The implementation team use the latest core library to build apps for our clients and different lines of business. They also update all of those implementations with the latest core version every release cycle.
Because the user stories for the implementations often require some core work to be done, I am having trouble organizing the different projects and boards... We are currently creating all of those stories in core, but we loose the ability to track time/cost on a per project basis.
In an ideal world I would have 1 project with sub-projects, and one big sprint for everything all in one view, while keeping the ability to track time/cost on those "sub-projects". But that doesn't really exist in JIRA (or at least I don't think).
JIRA portfolio may be part of the answer, but after watching a bunch of videos and reading loads of documentation, I just get more mixed up about what everything should do, and how they work together.
Thanks in advance!
In BigPicture plugin for JIRA, you can pull multiple projects into a Program and have the one-all view via a Gantt chart and Resoures board. Time tracking is available, for costs you can use custom fields and grouping/sorting/quick filters to make things more convenient. Recently the Teams module was also introduced.
I would separate the issues using two Components, or at least one Component for Core. When an issue is created, it has no Component. In a Planning meeting it gets assigned to a Component such as Core and that sub-team works on it during the iteration. The teams aren't too large, and the workflow / release timing is in lock step, I would consider them as one team with two specialties.
A User Story would typically only dictate the feature the user wants, not that it needs to be in Core or Implementation, Which group does the work can be done during a Planning meeting or by a Team Lead. Keep the two teams close to communicate when Implementation can expect changes to Core and keep your iterations short and coherent.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG