How to manage multiple projects in the same sprint

[Rafael Alencar]

We are software development company and we have multiple teams and multiple ongoing projects.

One dev can be in more than one project at a time. The main problem that we are facing is that in order to manage multiple projects we need to start and manage multiple sprints separately.

Is there a way to assign tasks of multiple projects to a single developer in a single sprint? And what is the best way to manage this kind workflow?

Thanks.

[Nataliya Vasyliv_Reliex_]

@Rafael Alencar

If you consider to use a plugin you can look at ActivityTimeline plugin. It provides users with an extra level of flexibility when it comes to planning the team’s work, as it allows them to schedule work not only for individuals but for the team as a whole.

In one Planning board, you can operate with multiple projects, teams, individuals, and milestones.

Let me know if you have any questions.

Best, Nataliya, ActivityTimeline Team

[Nic Brough -Adaptavist-]

The easiest way to think of this is:

A project is a container for a set of issues that are related and need to be configured similarly.  It can be a team thing, but it could be a department, a service desk, a product, and and and.

A team is a group of people to whom you give work.

The trick here is to assume that a board = a team, rather than a project = a team.  If you're working on a board, you are part of the team whose work is driven by that board.  You can be in many teams, and, most importantly, a board can draw its issues from many different projects (adjust the board filter to view what the team needs to see)

[Rafael Alencar]

Hi @Nic Brough -Adaptavist- 

So in order to achieve this, I would have a "parent" project with a filter the hooks the issues for other projects and then I would create the sprint in this parent project?

Sorry I'm new with this concepts, can you send me a guide for this filters thing?

[Nic Brough -Adaptavist-]

No, you set up boards that draw in the work for each team, doesn't matter what project the issues are in.

[Rafael Alencar]

Ok, if a board is for a team and each team can work in many projects how can I manage Epics and Stories? Is there a way to subdivide them inside a board?
This flow is not clear to me.

[Nic Brough -Adaptavist-]

You could, but it probably isn't the best use of board functions.

I think I am struggling to explain this well (been doing this for too long, assumptions creep in).  So I think an example might be worth explaining.

Let's say you've got three products - fleebs, schlamis, and blamfs. 

These are all coded or built in different ways, and so they need different versions, components and maybe their stories, tasks, issues, defects, improvements and so on may have different fields.   

 ( Note that that list of things is just a list of names you might want to use for different issue types.  Jira Software works with a simple hierarchy of Epic -> Issue -> sub-task.  You can have many different Issue and Sub-task types, all with different names.  But stories in Jira are simply a named type, at the Issue level.  Epics are an odd type of their very own. )

The best thing to do in Jira for these is to have a project for each product, enabling you to configure them all differently.

Now, you have teams run by Alice, Bob and Charlie, all of whom may need to work on the issues within each project.  So you give them the permissions they need.

Then you create three boards, one for each team.

Boards are a view of a selection of issues.   You will need to create something that will allow the boards to know which team an issue is for.  

In the default way Jira does things, boards select by project, but as you've got team issues in different projects, you are going to need to do it a different way.  Boards can be based on saved filters, and they can be anything you want.  (In fact, the default for projects just creates a filter for "Project = XYZ")

Most of us will do something like naming a team on the issue, with a custom field or maybe using one of the system fields.  

I often set up something like the below, which is a bit more flexible than what I've described above, hopefully it'll be self-explanatory:

(Project in ( fleebs, schlamis, blamfs ) and team-field = alices-team ) or labels = attention-alice

(Project in ( fleebs, schlamis, blamfs ) and team-field = bobs-team ) or labels = bob-bob-bob

(Project in ( fleebs, schlamis, blamfs ) and team-field = charlies-team ) or labels = hey-charlie

The label clause lets you draw in issues from other projects, which can be useful sometimes.  Might not suit you, I'm just trying to show that it can be quite powerful.

So, now, all three teams can work across all three projects without tripping over each other.  Each team board has its own sprints.

The only extra work you will have to do, compared with a simple "team = project = board" is getting people to triage the team selection field properly. 

This can actually work well for your Product Owners, because they can have a backlog of "everything" in a fourth (kanban) board, and they're best placed to select which team gets which issues.  Or, you can automate it - don't use the team field, but look at something else on the issue that the creators will have to enter when they create (a good example I ran into the other day could be described as User-interface, Server-Code, Database.

Lastly, I mostly ignored Epics there.  Epics live in projects, but are intended to be linked outside their own projects.  Depending on how you configure them, you may not need to think about them, they'll just work, but it might suit you well to add them to the filters explicitly:

(Project in ( fleebs, schlamis, blamfs ) and team-field = charlies-team ) or labels = hey-charlie or issuetype = Epic