Is Portfolio for Jira the right place to do high-level cross-project activity break down? How?!

Daniel_rccoqu

I have a “chicken or the egg” dilema! 😊

We started using Jira a few weeks ago,  and would like to use Portfolio to plan and manage our product roadmap. Our system consists of several products, and we have assigned a project/board to each product.

A new "system" feature (Initiative) will typically include activities (Epics and Stories) across several project/products.

So here is my dilemma/question:

From where in Jira should we do our highest level of task breakdown when we discuss new Initiatives? This activity will involve:

• Breaking down of Initiatives into Epics and Stories that belong to different projects/boards
• Populating these  Epics and Stories to different projects/boards.

In the very beginning, our project boards are empty, and as far as I know to make an aggregated Plan in Portfolio  one has to pull information from projects or boards.  So where do we start?!

Should we make a dedicated project just for the sake of doing our “system planning”? And pull the information from there to make our very first Portfolio plan? 

I appreciate all help and support.

Thanks
Daniel

Larry at Isos

I'd start by adding all the boards or projects for the products, this will also add teams for each product. I prefer to use the boards as sources rather than the whole Jira project as the teams are more often only paying attention to issues that appear on their board.

Regarding Initiatives, I recommend creating a project that just holds the Initiatives issue type, but it's ok if the Initiatives are in the same projects as the Epics and Stories. I like to use a seperate project so I can have unique Jira Project permissions for the initiatives. I typically . use this Initiatives project as data source for my plan, rather than creating an Initiatives board.

With that configuration, you can see what activities and commitments you are currently working on and start planning (assuming you already have work in those projects/boards).

However, you can also add new epics, stories, tasks, etc right in the plan. You would need to pick which Jira Project and Team the new work item would be associated with.

Because you are entering new work in th plan it would not actually be present or visible in the Jira project(s) until you Commit your changes to Jira.

So as long as you don't commit the new work you are planning to Jira, you can see how your plan would layout with the new work, without those new items appearing the actual Jira Projects. You'll notice these work items will be listed with their Jira project code but will be missing the -XXX numerical part of the IssueID, which makes sense since the aren't really issues yet. (So when, in the plan, I created an Epic in, say the IOS project, it's issue ID would be listed as "IOS" in the plan. An Epic that's really in the Jira project would be listed as IOS-16.) 

if the new work is very complex, I use the Scenario feature when doing this That way, if/when I get questions about how things are actually going today, I can flip back and forth between the currently in place "how things are going" plan, vs. how our plan might go when while we ponder how the new work will impact our teams. Once the new plan is ready to go I commit the issues from the tentative scenario, and then the tentative scenario would "take over" as the plan that reflects how things are actually going. I rename the new scenario and delete the old "how things are actually going" scenario as it's no longer relevant or up to date.