Using advanced roadmaps with component teams

[Dennis Rietmann]

Hello community,

I'm evaluating Advanced roadmaps at the moment and it doesn't seem to work for our situation, but maybe you see something I don't :-)
Our situation as follows (simplified):
We have component-based dev teams, e.g. frontend dev teams and backend dev teams (there's several others but let's keep it simple for now). We do not have fullstack devs.

In Jira we create features (stories) for each feature (e.g. "support markdown in the comment field"). A feature has several subtasks, some for devs from frontend teams (e.g. to build UI) and some for devs from backend teams (e.g. to build the API, business logic etc.).
I don't see how to do capacity planning with Adv. Roadmaps in this case, as I can assign an entire feature (story) only to a single team. However in our case there's subtasks in the feature assigned to people from different teams.

Do you have an idea?

[Björn Gullander Eficode · Accepted solution]

Hi, 

You're right that on story level you can only assign an issue to one Team (and the sub-tasks are automatically connected to that team).

What you may think of is to change what kind of work is defined on which level. So instead of defining the work on story level you could define an Epic for the same thing. Then you could divide the stories between different teams instead of sub-tasks.

Then you will be able to track the work for each team easier. The advantage might also be that you may split the stories into different team boards if you want. Something that is not possible when you share sub-tasks in between teams. 

[Rick Olson]

What Bjorn described is pretty much what we do.

We have separate component teams in Advanced Roadmaps (AR) and each team has their own board of backlog stories. All teams work from the same Jira projects and we use the component field to separate the work by team.

When we have a project to work, each team creates one or more epics for their team and, within those epics, they create the collection of stories their team needs to accomplish. We added a level above epic, in AR, that we called Initiative so we can create reporting at the project level.

In AR, our sources include all of the team boards that, when all work is pulled into AR it gives us a big picture the work for the project. By using the velocity, by team, we can see the projected sprints that AR derives for each team. For us, we increase or decrease the velocity of each team (i.e. adding/removing staff) until we have target end dates that align with required delivery dates.

For forecasting, with each team having their own collection of stories for the project, we can do preliminary estimates at the epic level to give us a rough cut at the number of projected sprints, per team.

Operationally, we use dependencies to link stories across teams so that our scrum-of-scrum meetings enable scrum masters to work out sprint content of upcoming sprints.

[Dennis Rietmann]

Thanks for the feedbacks! That organisation makes sense with Advanced Roadmaps and I think it's the intended way to use it.

In my case I can foresee it will lead to the creation of a lot of unnecessary tasks for smaller development efforts, e.g. now I have a feature (story) with 2 tasks, 1 for the component A (e.g. backend) and one for component B (e.g. web). 

With the proposed structure I would have to create:

• An epic for the feature (not assigned to any team)
• A feature for component A (assigned to component A team)
• A feature for component B (assigned to component B team)
• A task for component A in the feature of A 
• A task for component B in the feature of B

-> That organisation would work well with AR but increases the task count from 3 to 5. 

I guess AR is then just not made for our use case and I'll be continue the search for another tool.