What is the best workflow between Jira and Confluence?

Question

I'm struggling with Jira and Confluence. My Team and I are developing an application and we are not sure how to structure our JIRA environment perfectly. For our development process we use Kanban.

Now, for each App (Android, iOS, Web and the back-end) we have separate projects in JIRA. So we have to create each epic and story 4 times. This is not very efficient. Is it better to create one Project in JIRA e.g. "Software Project" and create there several boards for each app in it?

Is it right to start by creating a Product Requirement in Confluence, define there our User Story and create these stories in JIRA? I mean every App has the same epics and stories but the have different Tasks. How do we manage this?

What is the perfect structure in JIRA and the best Workflow between Confluence and JIRA for our workflow? We are looking forward to using Portfolio. Is it recommendable?

Answer 1

It sounds like you might be attached to your current setup, but I'd recommend that you rethink the quadruple stories.

Are you really claiming that you can be done with the Android item but not the back-end, and you can move on to the next Android item?

Instead, I would recommend that you have a single item on your Kanban board and that it encompass all of the layers (Android, iOS, Web, and back-end).

The "I want to change my username" item is only Done when it works across all platforms.

This is assuming that you want your application to be the same on all platforms. If you're okay with your iOS app being three months behind the Web version, then separate items makes sense.

Answer 2

It sounds like you may be better off if you change your projects into epics (Android, iOS, Web and back-end) as this would give you better visibility in Kanban of a swimlane view of the tasks in Jira.

This would also allow you to more easily identify shared functionality that only needs to be done once for the three versions of the product, like back-end processes. You would also have less duplication of stories.

You could use more cross device epics & break down further before the stories (eg UI, Admin Panel, Checkout).

Answer 3

@Fred vom Jupiter, can you share how many teams and what domain areas you have per team? I see you have 4 products:

• Android App
• iOS App
• Web
• Backend

If you have single team that handle all those project. I do not see point in creating 4 projects for each. Think about projects, not only from product POV, but also from team POV.

I sometimes find better organizing projects by teams, that work on products.

Example:

Team 1 (T1) - Works on Product 1 (P1), Product (P2); Team 2 (T2) - Works on Product 3 (P3); Team 3 (T3) - Works on Product 4 and occasionally on P2 and P3;

I will two JIRA projects:

• JIRA1 - Backlog for projects P2 and P1; T1 will sprint there;
• JIRA2 - Backlog for project P3; T2 will sprint there;
• JIRA3 - Backlog for project P4; T3 will sprint there;

However if T3 need to take stories or work on stories from JIRA1, I will transfer those stories to them.

I usually use labels to track what feature is from what product, as sometimes requirements from product can be cross-project, or multiple projects.

Keep in mind that you should slice stories by the principle of the cake. You might want to rethink how teams are structured to optimize for the feature flow instead of keeping them into department/functional areas.