Should You Have Multiple Boards in a Jira Project?
Вставка
- Опубліковано 29 вер 2024
- Thinking of having multiple Jira boards? Check out this video to see the good, the bad, and the ugly.
😀 If you are enjoying the content and want to help support the channel, check out the links down below!
👨🏫Udemy
🔴 Jira Fundamentals Course - www.udemy.com/...
🛒Apetech Merch Store
🔴 my-store-dc4ae...
✅Subscribe to The Jira Life
🔴 / @thejiralife
👇And don’t forget to check out channel sponsors down below!
Released
🔴 released.so?
💲Discount Code: RARNAPETECH
#jira #atlassianjira #jiraprodructdiscovery
To get more resources and get in contact with me check out this link linktr.ee/apetech
Can you have separate automation for each of the boards within that project?
Thanks for the insightful overview! I wanted to add that having multiple boards can actually be pretty cool if done right. It's all about keeping things organized and setting it up smartly.
Let's take the example of the QA team. They could be responsible for multiple feature teams, and that means the QA board might cover the issues from different feature team boards. I wouldn't call that contamination, more like efficient collaboration! 😉
When it comes to different issue states, you have the power to define exactly which states match up with each column on your board. Jira is incredibly flexible and powerful. Just make sure you follow uncle Ben's advice: "With great power comes great responsibility."
Well said! What are your thoughts about QA being in a sprint board or a kanban board? I have my preference which didn't make it into the video, but would love to hear your thoughts.
@@ApetechTechTutorials that’s a whole other topic. At Atlassian, we moved away from the traditional Q&A model 15 years ago.
Instead of throwing a product over the QA fence and letting a team run tests in isolation, we reduced the number of people dedicated to testing and instead invested in training and assistance for developers. Basically integrating testing, just like design, more tightly into the development lifecycle.
Long story short, it would be on the same board. In fact, there wouldn’t be a seperate issue for it, just a column in the process.
@@Released-po4zw Maybe the topic for an episode we can do together!
I generally recommend just a single board in a project, and if you need different views of that one board then create a Quick Filter to toggle the issues on the one board.
The only time we have done multiple boards in a single project is the exact scenario Alex mentioned, which is we have a board defined for each of our scrum teams, that shows a view of all their issues in their sprint assigned to them regardless of what project that issue is in. This gives our teams the ability to work on multiple products in the same sprint (we have a project per product generally) and have a holistic view of all their work on a single board. Team is single select, as Alex suggested, and we have all the Team Boards in a special "Teams" project separate from the product projects. Another benefit of this is we are able to do surge work and have multiple teams work on the same product for a period of time (tickets from the same Jira Project backlog), or we can have them focus on different products. It seamlessly allows connectedness between the team and the work they do, without putting in a hard connection between teams and products
100%
Hi, I am a designer looking to build my first web app. I have the wireframe planned out and all the designs, but I am little unsure on how I would setup a something like a Login Page in Jira. I have created a Story and explained what it needs to be, then created a child Issue of Design Login Page (for me), child issue 2 = Convert Design into HTML + CSS (for developer 1), child issue 3 = Code html + css completed page into Live to work with database (developer 2). Just wondering would this be the best way to do it? Thanks
I think it’s a good start, but your stories and child issues are still a little toooooo big. If you can guarantee that you can finish the “task” by the end of the sprint, then you might be fine. But if you find that the work isn’t being completed on time, then I would recommend you make your tasks smaller. Tighter, better defined scope.
Idk if you are going to respond, but right now in my company I created 2 boards because one board you can call its for marketing and operations, and the other one is for developers and QA, as of right now both use Scrum not Kanban. The marketing board has an issue I created that has a differetn workflow vs the software standard that Jira has for the dev board Do you think that's the best thing to do or do you have a recommendation.
This is great content !!!