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; } } }

Is is possible to have a different board per sprint?

Steve Trotter

Is it possible to assign a different board layout per sprint?

For example:

Sprint 1 - is a development sprint
Sprint 2 - is a testing sprint

I need different columns on the board view for the development sprint versus the testing sprint.

Note that I've also activated the parallel sprints feature, so on the board view I can see a "switch sprints" option - which ideally I also like to switch board layout.

Accepted answers

Tarun Sapra

Boards are nothing but a "view" on the issues. Sprint is not based on boards rather it's on issues which belong to the sprint. As sprint data is carried by the issues.

Thus, if you write a JQL filter for a new board such that it fetches the issues on the board having sprint X then you can start Sprint X on the board. But one issue can't be part of 2 different active sprints. Thus, yes it's possible to have different boards per sprint.

But why do you want to have separate sprints for development and testing as both of these activities should be performed in the same sprint in Agile way of working. i.e. Devs and QAs should work side by side.

All comments

Tarun Sapra

Boards are nothing but a "view" on the issues. Sprint is not based on boards rather it's on issues which belong to the sprint. As sprint data is carried by the issues.

Steve Trotter

Thanks for the reply.

What I'm experimenting with is different ways to represent phases of a project in terms of how we work. I'm using sprints as the phases in this case.

In the development phase - the workflow is shorter.

In the testing & deployment phase - devs and test work side by side but the workflow is longer. We also work with end clients, not an inhouse product.

So when in development phase, there are fewer columns on the board as per the shorter workflow, then be able to switch to testing phase (and close down the development phase) with the extra columns appropriate to longer workflow.

Some clients we work more agile with, others by necessity are not. It's the latter case here.

Do you have any other ways I could represent the above?

Tarun Sapra

You are doing right thing. I have done something similar at a client wherein one workflow is is supporting both dev and deployment. Once dev phase is over the issues are moved to done on the board and the "done" column of the board is mapped to "ready for deployment" workflow status and that automatically publishes the issues in the "to do " column of the second board meant for deployment. Thus, one workflow but two boards and issues automatically transition from one board to another based on JQL filter.

Steve Trotter

Great, thanks, good to hear I'm heading in the right direction

Welcome!

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

Quick Links

Find more posts tagged with

jira