Scrum board dependencies

hi,

I have few questions and need help

1. can i create 2 scrum boards in a project?

2. How to show dependicies betweeen 2 scrum boards in a project in JIRA. For example consider a scenario where in scrum board as one swinline whis is "To Test". Once any user stories in this swimline, it should be placed automatically in another scrum board so that that testing scrum board gets kick started. is it a good way to do that? If so, how to show this dependency in JIRA. Please clarify at the earliest

1 comment

1. No.  Boards do not belong to projects, so you can't created 2 scrum boards in a project.  You can't create any boards in a project.  You can create as many boards as you like, and have many of them look at the same project though.

2.  You don't.  Issues do not "move between" boards.  A board selects a set of issues, and then displays them according to the sort order, columns and swimlanes set for that board.  You *can* set up boards so that an issue will not appear in it until it reaches a certain status, so you could have an issue that moves across board 1, and only appears in board 2 when it gets near the end of the cycle.

for the first point and second point that you have mentioned, can you tell me how to do that so that i will try to simulate it? appreciate your support.

 

Ok, let's take an example where you've got two teams, developers and testers, with a workflow of

Open -> in dev -> waiting for test -> in test -> closed

  • Create a filter called "dev" for "Status in (Open, in dev, waiting for test)"
  • Create a filter called "test" for "Status in (waiting for test, in test, closed)"
  • Create a "dev" board with columns Open, in progress, done.  Create it from the dev filter, and map the three status (Open:Open, In progress: in dev, done: waiting for test)
  • Create a "test" board with columns Open, in progress, done.  Create it from the dev filter, and map the three status (Open: waiting for test, in progress: in test, done: closed)

You will now find developers move stuff across their board, and when it's "done" for them, it appears in the "open" column for the testers.

  • 1. Waiting for test swim line needs to be in common for both boards?
  • i guess, we will need to create two boards first and then create filters. Is it correct?
  • if a put a user story in swim line "waiting for test" in dev board, would that come directly to Test board? Pls explain
  • if I close that userstone in Test board, would that be automatically marked as Done in Dev or do we need to manually move that story to Done in Dev board?
  • i don't think we will need to maintain another sprint backlog for test board ad this board typically depends on  Dev board

 

No, you're using the term "swim lane" incorrectly.  A swimlane goes across columns and groups up issues for varying reasons.  They're not relevant to what you're trying to do.  We are talking about (groups of) status in columns.

You will create two boards, yes, but do the filters first, as you can then use "create board from filter X".  That's why I put them first on the to-do list.

The "waiting for test" status needs to be in the "done" column on the first board, and in the "open" column in the second board.

What the setup above does is hide things the users don't need to see.  A new issue will be visible to developers, they move it to in-progress to work on it, and then when they move it to "done", it becomes "waiting for test" on the tester board.

You could do the tester's board as a Kanban, or not even bother, and get everyone to work from one scrum board.  But if you do that, then your testers and developers will need to estimate *together*, or you won't get sprints planned correctly.

If I use tester board as Kannan, will not be able to see burn down for test team and that's the reason why I opted the above approach. However have asked other questions in my previous reply. Would you pls help on that

I have answered all of your questions, I'm not sure what you're missing from there.

You are right that a Kanban won't have a burn down, that really does mean you need Scrum.  If you use one board, you won't have a "test team burndown", just a "whole team" burndown.  If you use two, then you'll get separate burndowns, but you will have to be careful about what happens when sprints are opened and closed (you will want the dev team to close a sprint and the test team plan and start theirs as soon as possible after that)

Thank you do much. If I put a user story in ready for test in Dev board, would that come automatically to test board? Can we configure like that? If so, can you tell me the process? And also, for the steps that you have mentioned above, is there a step by step documentation? And also I believe on sprint backlog is enough for both the boards. Is my understanding correct? If so how to configure that in jira?

>If I put a user story in ready for test in Dev board, would that come automatically to test board? Can we configure like that? If so, can you tell me the process?

Please see the answers and comments above

>is there a step by step documentation?

No, I've assumed that you know how to do basic things like "create a filter" and "create a board"

>And also I believe on sprint backlog is enough for both the boards.

A scrum board is partly defined by having a spring backlog - that's what it is for.  Each board has its own.  They have to, because each board could be working on a different set of issues.

Hi, I am not a seasoned JIRA admin. Hence, requested as i am thinking of the model stated above

I can't really explain any more, I don't know what you're not able to do from what I've said.

For boards and filtering though, see https://confluence.atlassian.com/jirasoftwarecloud/creating-a-board-764477949.html and https://confluence.atlassian.com/jirasoftwarecloud/searching-for-issues-764478280.html

thank you. Hopefully one final question..

Is there a way that we can automatically transfer some stories in one scrum board to another scrum board within or outside a project?

You have not understood what I have written above.

There is no "transfer" because Issues do not "move between" boards.  A board selects a set of issues.

I have shown a simple set up where an issue will be selected by different boards at different times in its lifecycle.

Comment

Log in or Sign up to comment
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,748 views 18 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you