Configuration for multi-Sprint and third level

Question

We have single Jira Scrum project (TTSB project key) configured for multi-sprint (multiple active sprint at the same time). We want to use Easy Agile Program (EAP) under this configuration.

We have created two additional Scrum boards: ENG, REP filtered by specific components. I tested EAP under the following configuration:

* Team Agile Boards: ENG, REP
* Third Level issue source: TTSB
* Program Roadmap: Option A: Schedule epics from the selected agile boards
* Sprint source: Teams independently manage their on sprint on their board

Under this configuration, I am able to create the sprints for their own board and EAP is able to identify them. So under this configuration, I am getting what I expect. Once the PI execution starts, I can activate for example the first sprint from ENG and REP boards respectively. This is what I am expecting.

Is the above configuration the optimal one for my purpose?

All the issues and epics, have associated components, exept one epic and one story. Because they don't have component they are not part of the ENG, REP boards, but because I am using as a third level issue source the main board of the project TTSB, I was expecting to see them in EAP, but maybe I am not fully understanding the purpose of the third level.

If I add TTSB board as a team agile board too, to try to get such epic, and story with no component, then it forces me to create Sprints for such board, that i don't plan to have any sprint. I was thinking about such epic/story as a work that was not initially identified by the ENG and REP boards, but as a result of the PI-Planning we can include them.

I was reading this link: The third level hierarchy. It seems to be used to filter a collection of related epics, but it is not clear, what information should have such board, epics, or any superior hierarchy, such as features created in Jira Advanced Roadmap, for example, or maybe epics from that board that have some dependencies with the epics from the ENG and REP boards, so it serves as kind of filter for the board selecting just the epics from the team agile boards that have dependencies with the third level. Is this the use case for using such third level? What is the purpose of this third level and how can be properly used?

Thanks in advance for any help

David Leal_28ge8x · Answer

thanks @Henri Seymour {Easy Agile} for taking the time to meet with me and give me the opportunity to share with you some of the feedback I have.

Henri Seymour {Easy Agile} · Answer

Thank you for taking the time to meet with us to talk about how you and your teams use Easy Agile Programs! We appreciate the opportunity to talk through your situation and feedback.

I can see how Easy Agile Programs is missing some features that would be useful for you and your teams working with a single Jira project managed using Components. Given this situation, we understand that the third level of hierarchy the based on an additional Jira board is not as useful for you for viewing your teams' plans.

We’ll be sure to let you know if we have any updates on the suggestions you’ve raised!

David Leal_28ge8x · Answer

Thanks @Sara Hekmat yes, you are correct, with Jira Advanced Roadmaps (JAR) you can achieve it in a very elegant way, adding a third hierarchy via initiatives for example. Maybe in that case it makes more sense to use the third level, because you can connect your epics to your initiatives and have the board of your initiatives as your third level with all the initiatives. I guess this is the use case, if I am not mistaken for using this third level to connect your initiatives.

The problem is that my managers ask me to avoid using initiatives as an additional hierarchy, they want to see the PI Objectives related to epics, so all the information in the same project, so the team can focus on implementing epics, so they don't need to go to another Jira project/board to see the initiative information. Using team field is a good approach, but this field only accepts a single value, so the way to represent shared work is assigning one set of epics to one team and another set to another team and both set of epics contribute to one single initiative. This is a good approach, but it requires to add a third hierarchy to represent it and this is not what my managers want.

As I mentioned in my response to @Henri Seymour {Easy Agile} there is a pattern using components, where you can achieve the same without having more boards or adding an additional hierarchy. It has the risk that team members can assign by mistake the wrong components and the work will be visualized in the wrong board, but on my teams the user story creation is controlled by the BA's (one per team) so this risk is minimized. Then we have automation rules, to propagate epics components to the user story that triggers on creation, so we don't depend on manual work from the BAs to add the component every time.