I have seen several questions about this. I just want to be sure that we need to HACK our way arround the system.
In my mind comming from a physical world. When I create a board, I think of it as a physical board.
So if IRL i have a board for a team it is a whiteboard next to the teams location. If I have a sprint it is put up on that board. So Team A and Team B each have a board and each have a sprint that runs paralell. They sare the same backlog as they are working on the same project. But they dont see each other stories as they are on the other teams board, then they have to walk over there. This makes sence.
In Greenhooper you create a board for Team A and Team B. And you can create a Sprint 14 (A) for team A and a Sprint 14 (B) for Team B. But they both see eachothers sprints in thir board view and have to use filters to remove the other teams sprint. And you have to remember to lable all issues to a team in order to filter them. Lots of human error and it causes lost/forgotten issues.
For me this just seems wrong? Or is it just me, is there something I am missing. Or is my perseption of how it works IRL wrong?
Are there other ways of dooing what I would like to do (seperate view for each team, seperate filters, seperate reports for each team but a common backlog)
I guess it seems natural that, if you want the feature set provided by IRL, you would do well to simply use IRL post it notes and disregard the Boards in GreenHopper.
That said, it seems like a Swimlane Strategy that looks like:
assignee in (team1member,team1member,team1member)
assignee in (team2member,team2member,team2member)
would allow you to see each teams' workload seperated without any of the messiness of labels and associated human error. Or, quickfilters of the same by-assignee-group nature.
Finally, if you're committed to using labels, there's the option of filtering for issues assigned to users in the team and bulk editing in the apropriate label.
We just thought of that; making a team filter with assignee for all the team members as you sugested. That helps a lot.
Swimlanes seems to be a good idea. We will have to try that out.
In responce to IRL: If I wanted to do IRL scrum I would not be useing software. I would like this software to solve my problems in an easy and understandable manner.
Jira properbly just have to solve a lot of different workflows and therefore it handel some better than others.
This is very much correct. As Agile focuses on the single-backlog, multifunctional team, there's a very egalitarian approach to all issues being visible as much as possible. While this works okay with the traditional 5-person team, larger teams do benefit from better filtering and bucketing.
How will this help?
When I have tried, it does not matter in what bord you create a sprint, all boards shows the sprint if they are working on the same project. Again it seams wrong? A sprint should belong to a board, a board to a project. The way it works in our jira is that a sprint belongs to the project, and is shown on all boards.
Actually you don't need anything special. Enable parallel sprints in GreenHopper labs, and plan parallel sprints for each of the team (one sprint of course per team) (Use team name in the sprint name to identify easily) and you can use the same board for everyone. And for product owner, if the filtering is not applied for a particular sprint, he can see the overall status as well.
...And if I only have one sprint, I cant get a report for each team. Then it is hard to do SCRUM.
The big problem is the planning mode. Haveing 5 teams we need 5 sprints in one board planning mode. This is a mess. Haveing a backlog of over 500-1000 issues makes this even more a mess to move arround, when you only can organice by dragging and dropping.
We need ekstra 5 sprints in the end of a Sprint when planing a new one.
So imagen; in planing mode you have 10 sprints to manage each with maybe 10-50 stories. Even if you minimize all you can hardly see the backlog on the screen. Now you have to move 10-50 stories up into the top sprint by draging. Now IRL seems a lot easier.
If you could isolate a sprint inside a board but share the same backlog this would not be a problem! You would only have to organize two sprints at a time.
Hi @Devesh Agewal, wow an old topic, back from when I was trying to figure out how to work with Atlassian tools, with 7 teams on 3 projects.
To get arround this you can do it in two ways.
A) (The right way) Create a custom field called teams with a dropdown (one choice only). You will have to remember to set this every time an issue change teams, lots of human error. Happens a lot at my work. On the upside you can use unassigned. Downside it is hard to have autoassigned issues to components (but mayby you can just set that to the PO instead). You then filter a board (general filter) by this field.
B) (The way we do) You make a extra user for each team (TeamA, B ect.). This works as unassigned for that team. You then filter the board by members of the team and this extra team user. Here you can set a component to a team user and it will auto assign to that team. When you have a huge product and not everybody know which team is in charge (owning) of what this is really good. But when team members change this can be a little messy, you have to change the filter.
Extra info: We have a PO for each team and a backlog for each team. We also have a common backlog outside in a spreadsheet for the whole project. Would like to use Portfolio for that. We could also make another board for a this common backlog with only Epics and all teams
A good thing to remember is that unlike IRL, you can have as many boards as you want. They are free. We actually use 3-4 boards for each team. One for sprints, one for stabalizing, one for QA, and one for the PO.
I hopw this helps someone out there.
Old topic, but still relevant. For anyone wanting to try @Christen Lorensen 's answer using Components, this video explains it really well: https://www.youtube.com/watch?v=Ym_kBoFZORI&ab_channel=JiraTraining
The approach we take is this:
1. Manage the larger and potentially ungroomed backlog in a separate "product backlog" project.
2. During release planning, move more qualified issues/stories to the "release backlog" project. In our case we have multiple separate projects for different teams and products.
3. A project only belongs to one board - that keeps things simple. In some cases we have one, in other cases we have multiple JIRA projects in a board. Having multiple teams working in the same JIRA project needs to be done very carefully and partitioned clearly based on issue type or fixversion which would be assigned in the product backlog before it is moved to the release backlog.
4. If this doesn't work and you really need multiple boards/teams working in the same JIRA project, keep in mind you can modify the filters for a board, and the quick filters work great as well.
Thanks, nice to see a real world example, of how other people do it.
We are working on the same projekt, and therefore have to have a common backlog.
We are going to try with having a board for each team, one for the project manager, each with seperate filters. Only one common sprint with filtered Swimlanes. Later we might have several sprints at the same time.
I think the problem is that one of the "features" of rapid boards is to have multiple boards look at the same sprint. Right now, I have the exact opposite scenario as you. I have one team with multiple projects. So I created a board with all the projects. Some of the team members only care about one of the projects so they have another board with the same sprint that just shows their project while others have a the board that displays all the projects. If they were to make the sprints per board, we wouldn't be able to do that.
What's interesting is that my scenario could be addressed in other ways, like providing more on-the-fly view settings and filtering for a single rapid board. That way users could customize the rapid board on the fly totheir liking. Your scenario would require a sprint to be associated with a board.
This actually makes sense.
So Greenhopper solves singel teams problems like this well, and don't handle multiple teams that well.
In my mind what you described is board view, not a board. It is a certain way which you look upon a board. IRL you would properly make swimlanes to divide different projects on a board, and the person would IRL only look upon the swimlane and filter the other projects out in his mind (focus).
So the structure should be: project -> board -> sprint, and a board could have several board views.
A board in my mind is a white board and this can be organized in different ways, here as you say software can help and organize the same board in lots of different ways at the same time. The feature I am requesting is as far as I can figure out, not been made yet. So I have to do work arounds in order to achieve something similar. That was what I wanted to know, now I do thanks.
We have the same problem. We run a single backlog with multple teams running parrallel sprints. When using Greenhopper, each of the team's sprint boards show all items committed in that sprint no matter what team they have been assigned to.
Are we saying Greenhopper is not capable running a single backlog with multple teams running parrallel sprints, without applying some kind of work-around as highlighted above?
I have changed a bit arround here, now I think it is smart. It is like having a huge whiteboard everybody shares, and you have a guy changeing alle the issues arround to what you want to focus on.
The board and the seperate quick filters for each board does this. In that way it is like having several seperate boards once to turn on the filters.
I also found out when planning a sprint it only shows up on the board where you are planning it, once it is started it is on all boards. And with greenhopper 6.1.2 you can assign issues to sprint and order them by right clicking.
Now I am only missing that you can assign issues to a spint(s) when you are createing it or editing it. (One click one bye, not: create, navigate to spint, find issue, move it to sprint)
For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events