Configuration for multi-Sprint and third level

[David Leal]

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

[Henri Seymour _Easy Agile_]

Hi @David Leal,

Thanks for your question about the new Third level hierarchy in Easy Agile Programs!

It sounds like you’ve started with an appropriate configuration to manage two teams working on the project TTSB in Easy Agile Programs.

You’re correct that the third level hierarchy enables you to filter your epics based on which bigger-picture issues they work towards. There are two requirements to make this work: date fields and issue links.

To see the issues your third level issues, those issues will need to use Date syncing with native Jira date fields to be scheduled during your Increment. Then, they’ll appear as “pills” at the top of the Program Board.

To connect the third level, you can add issue links in Jira between your third level issues and epics. Choose an issue link type that you’ve selected in “Link Type” in Easy Agile Programs' third level configuration. Then, you can select one of the issues to filter the Program Board down to only epics linked to the selected issue.

As @Sara Hekmat mentioned, it’s possible to use Advanced Roadmaps to create a hierarchy by creating an issue type above epics. If you do this, you can select a board with these issues and the link “Parent Link” to see the hierarchy from Advanced Roadmaps in Easy Agile Program

Our Product team are interested to talk with you personally about how the third level hierarchy can work for you. I (support@easyagile.com) have emailed you directly to arrange a time to meet to find the best configuration for you and your team.

Kind regards,
Henri, Support Engineer @ Easy Agile

[David Leal]

Thanks for your response, finally I was able to visualize the third level. In my opinion it is not really a third level, but basically a way to connect the epics with a third board. That links some epics with the team boards. I got it, the thing is that I don't see the benefit of doing this, but I am a beginner, I am trying to understand it.

Let's say we have an epicAB on this third board, and then you have epicA, epicB from team A and B respectively, we add dependencies from epicAB to epicA, and EpicB, by selecting in the third level the board where epicAB was defined, then you can visualize that epicA, and epicB are contributing to epicAB. 

Using components, since any jira issue can have more than one component, you can achieve a similar effect but at a story level. Let's say you have a single project: AB, and two boards (Board A, Board B) within the project filtered by component A and B respectively.

Then you have epicAB within the same project that have stories from both components A, B and the epic itself have component A,B (this is a way to indicate that this is a shared epic). In EAP you can see now that for epicAB, both teams are contributing with specific user stories, so the epicAB is done when all the stories from from the two boards are done. You can put epicAB as a shared feature, and when you are on the team planning, you can see specific team contribution to this shared epicAB.

The advantage of using a third level is that it allows to link epics, maybe intended for more than one Jira project, but it forces you to deal with additional boards. On contrary using the component pattern I explained, you have the third level from epicAB, without needing to add an additional board/project.

That is my point for a program that is defined as a single Jira project and using components to differentiate each team, you can achieve it in my opinion in a simpler way.

[Henri Seymour _Easy Agile_]

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]

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.

[Sara Hekmat]

Hi @David Leal

It seems you have JSW premium license, ideally, you should be able to use the Advanced Roadmaps Team field instead of assigning specific components to the issues. 

The Team field is a custom field in JSW premium that can be added to your project issue screens. 

Third-level issues (higher than epic) are used to track the work across different teams, for instance, if you have some initiative that is worked on by both the ENG and REP teams, then you can create a high-level (above epic) issue for it and create the teams epic as its children. 

Regards,

Sara

[David Leal]

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.