I'm using JIRA for agile teams for quite some time. As long as the teams in the project were cross-functional, everything worked straight forward, no problems. Now I got into a project that has component teams. All the teams are using the same JIRA project and use the Component field to distinguish between the teams. Having component teams means that for a single user story, we need several teams to work on it in the same sprint. How do I do that? The options I see: * Use a Story type for the user story, and then create sub-tasks for the component teams. In this case, the component teams won't have their own Scrum board (as there is no Scrum board for sub-tasks) and the teams won't be able to assign SPs to their work items (as you can't put story points on sub-tasks). * Clone the user story – one for each team – keep similar prefix title for all the clones. This will allow the teams to have proper Scrum boards, but you won't have a view of the real user story (the aggregation of all the clones). * Treat EPIC as user story, and treat Story as technical task. The teams will have proper Scrum boards. When you come to look at the real user story, you look at EPIC type ticket. So far so good. The problem is that you lose some of the reports. For example, EPIC burndown will actually show the user story burndown, so we loose the EPIC view reporting. I'm pretty sure my company is not the only company that has project with component teams. I wonder how such companies deal with this situation. I would highly appreciate the community wisdom on this J

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How component-teams can use Scrum board and still have user story view?

Erez Morabia

I'm using JIRA for agile teams for quite some time. As long as the teams in the project were cross-functional, everything worked straight forward, no problems.

Now I got into a project that has component teams. All the teams are using the same JIRA project and use the Component field to distinguish between the teams.

Having component teams means that for a single user story, we need several teams to work on it in the same sprint. How do I do that?

The options I see:

Use a Story type for the user story, and then create sub-tasks for the component teams. In this case, the component teams won't have their own Scrum board (as there is no Scrum board for sub-tasks) and the teams won't be able to assign SPs to their work items (as you can't put story points on sub-tasks).
Clone the user story – one for each team – keep similar prefix title for all the clones. This will allow the teams to have proper Scrum boards, but you won't have a view of the real user story (the aggregation of all the clones).
Treat EPIC as user story, and treat Story as technical task. The teams will have proper Scrum boards. When you come to look at the real user story, you look at EPIC type ticket. So far so good. The problem is that you lose some of the reports. For example, EPIC burndown will actually show the user story burndown, so we loose the EPIC view reporting.

I'm pretty sure my company is not the only company that has project with component teams. I wonder how such companies deal with this situation. I would highly appreciate the community wisdom on this J

Accepted answers

Jobin Kuruvilla [Adaptavist]

#2 is the one that usually works well (in my experience) because the component teams can have their own boards and concentrate on the piece that they need to work on. And, of course, priority might change for each component team.

Having said that, I have see that the program team also has a main story (not Epic) on its board that they track differently to the component stories. The program story will be linked to component stories and can be on its own board. That way, you get to track the main story and component stories separately.

Every approach has some advantages and disadvantages. I think the best one is the one that suits your use cases

All comments

Jobin Kuruvilla [Adaptavist]

Every approach has some advantages and disadvantages. I think the best one is the one that suits your use cases

Erez Morabia

Thanks @Jobin Kuruvilla [Adaptavist] for the prompt answer. My favorite choice was indeed #2.

Can you please elaborate more on the 'program stoty'? As far as I understand it is a story without story points (unless you manually set its story points which are the sum of the component stories story points). I assume you link the component stories to the EPIC. Does the program story linked as well and why? How do you track those program stories? Do you create special Scrum board that show only program stories? Who updates them?

Thank you!

Jobin Kuruvilla [Adaptavist]

Program story is the master story but it is estimated just like the component stories and it is not a sum of all story points on the component stories. It is usually assigned to the SME or a member of the program team and is estimated based on the effort involved in coordinating the efforts, meeting and any additional work involved.

It is linked to the Epic as well and it is up to you whether you want to track all the program stories in another board. I have seen both scenarios.

Erez Morabia

I see. I got the idea. Thanks!

Erez Morabia

If anyone else have different view or more ideas on this, please share.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server