You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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
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
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.
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.