Cross-project Agile Boards in YouTrack: The Best Recipes

Today we would like to tell you about cross-project Agile boards and monitoring your work progress in several projects through a sprint or any other iteration.

General use case
My team works on two projects simultaneously, and I want to monitor the progress for both projects on the same board.

One answer that springs to mind is, “Create a cross-project board. What could be more obvious?” True, but to make it work smoothly and fit your specific process, you need to configure the board appropriately, and that might be not so obvious. We’ve prepared three recipes to cover three common cases, so you decide which one suits you best.

Recipes: Three Ways to Cook Cross-project Agile Boards

Basically, creating a cross-project Agile board is easy. You click the Create button, select projects, add a search query to filter the cards on the board if needed, and it’s done. But with a cross-project board you want to see different projects with unique sets of issue fields and their values on the same board. Configuring that is the tricky part.

Creating a Cross-project Agile Board

Creating a Cross-project Agile Board

First of all, we need to define which of the fields should the projects have in common for a board to work.

On an Agile board you view features and their tasks during a period of time: sprints for Scrum-like processes, and continuous flow of work for Kanban-like processes. If you follow a Scrum-like process, you need to create a sprint, while for a Kanban-like process you can leave the ‘sprint’ unscheduled. Sprints in YouTrack are defined by a field of the type ‘version.’ Thus, the first essential ingredient is the ‘version’ field.

By default, sprints are defined by the ‘Fix version’ field. If you haven’t changed the system defaults, the ‘Fix version’ field is auto-attached to every project in YouTrack. The field is the same but with a unique value bundle for each project (as, of course, you rarely use the same version for different projects). However, a sprint on the Agile board is a particular version value. Thus, to view tasks from different projects on one board, these tasks should be scheduled on versions with the same name. So even if your projects don’t share the same bundle of version values, YouTrack would try to match their values from the different bundles.

So, matching version value is the key ingredient for cross-project boards.

Of course, there are other fields that define different entities of the board (like color-coding, or a saved search to use as the backlog, or estimation, etc.) but they are out of the scope of this post. Sprints are essential.

Now, let’s list the recipes.

Recipe One: Clear and Simple

The first recipe is obvious: the projects on your board have one common version field (generally, Fix version) and share one bundle of versions. Plain and simple. In this case you can use all the advantages of the Agile board in YouTrack: smooth creating and planning sprints by dragging tasks from the backlog to the board, moving tasks across the board columns, monitoring the progress on the Burndown chart and Progress bar, etc.

Cross-project board with shared 'Fix version' field

Cross-project board with shared ‘Fix version’ field

However, this recipe with same actual versions is not always applicable in real life. We assume that many of our clients would prefer to keep ‘Fix versions’ bundle unique for each project. This brings us to the second recipe.

Recipe Two A:  Matching Version Name

Let’s assume that you keep different bundles for ‘Fix version’ field values in project A and project B. You need to add the same value for the ‘Fix version’ field to both project. If you choose this version value as a sprint on the board, YouTrack would watch all the tasks assigned to this version from project A and project B and display them on the cross-project board. In addition, when you create a new sprint from the cross-project board, YouTrack would add the created sprint name to the both projects ‘Fix version’ bundles. We’d say this is the most balanced recipe, since you get to keep both unique versions in projects and get the advantages of the full-featured Agile board.

Creating a Sprint for a Virtual Version

Creating a sprint for a cross-project board

Recipe Two B: Virtual Version

Here is one more option for those, who prefer to keep different ‘Fix version’ field bundles: you can create and attach to all projects on the board a version field, which will be used only to define sprints on the board. Thus, you will see all the needed tasks on the board, but sprints will become a virtual version, used only for monitoring progress on the cross-project Agile board.

Planning a sprint

Planning a sprint

Recipe Three: Unscheduled Versions

The third available option is ‘unscheduled’ versions. You can use it if your team follows Kanban principles, or when one project on the board does not have a version field at all.

Let’s say you have projects A and B, and project A has the ‘Fix version’ field while project B doesn’t. Then, to monitor both of these projects on the same board, set ‘Fix version’ as the sprint defining field, and then on the board select ‘Unscheduled’ sprint. You will see all the tasks from the project A with Fix version = Unscheduled and all tasks from project B, which will be considered unscheduled as well.

Unscheduled sprint

Unscheduled sprint

Actually, you can get the same result with Recipe Two, when you do not actually need sprints (for example, if you want to get overall view of the amount of tasks in your projects). In this case you just need to leave the common ‘bogus’ version field from the second recipe empty, unscheduled.

In case of a Kanban Agile cross-project board with a continuous flow of work, you can monitor the state of your projects using the Cumulative flow diagram and the Progress bar.

Well, that would be all about configuring cross-project boards for today. However, there are still a couple of tips and rules for you concerning a cross-project board:

  • When you configure a cross-project board, you can choose a field to be used which belongs to at least one project.
  • When projects on the board have different states bundles, choose one and YouTrack will try to match the values from all projects. For example, suppose you select to show only states from project A on the board. But if project B has a matching state value (let’s say ‘Done’), the issues in ‘Done’ state from project B will get to the board as well.
  • You can mix swimlanes and tasks from different projects on the board. That is, you can add tasks from project A to a swimlane which is a feature in project B.
  • Use ‘project-based’ color-coding to distinguish tasks from different projects on the board.
  • You can use Estimation on a cross-project board, if at least one project has a field of the proper type (period or integer). In this case, all the tasks from the project without estimation field will be calculated as zero.

We hope that you will find these tips useful for your Agile practice.  If you already use YouTrack, the time is just right to ‘cook’ your first cross-project Agile board. If you still haven’t tried it yet, get YouTrack now and apply one of our top recipes!

We look forward to your feedback, thoughts and suggestions.

Practice Agile with pleasure,
YouTrack Team

This entry was posted in how-to, tips and tagged , , , , . Bookmark the permalink.

3 Responses to Cross-project Agile Boards in YouTrack: The Best Recipes

  1. Guillermo says:

    We are looking at using Youtrack to track several projects on the same board, with a scheme like the one in Recipe Three (Unscheduled Versions).

    These projects might be from different clients, so I would like to have a special user for each client as observer that can see (and maybe manage) only his/her tasks and boards. My idea was to add a “Client” field for all projects and then have a role with permissions set not globally but filtered by the “Client” field value. Can that be done?

    Can user permissions be assigned according to a field value for all projects, instead of in general for each project?

    • Valerie Andrianova says:

      Unfortunately, you cannot configure permissions based on the field value. However, if you want a user to be able to see the issues reported by him/her only, you can enable ‘Create Issue’ permission and disable ‘Read Issue’ permission. Hope it works for your use case.

      • Guillermo says:

        Since we want the user to see all project issues for a specific client value I guess what we will have to do is add him/her to each new project we set up for that client. Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">