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

One project; multiple teams, running parallel sprints

Christen Lorensen

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)

Accepted answers

John Garcia

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.

All comments

Renjith Pillai

How about:

Each team has a board for themselves (like the physical boards)?
Product Owner uses a third board which has all the issues and all the sprints?

Christen Lorensen

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.

Mark DeMichele

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.

John Garcia

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.

John Garcia

This is how GreenHopper adds value over IRL.

Christen Lorensen

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.

Renjith Pillai

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.

Christen Lorensen

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.

Christen Lorensen

But I still get all the sprints showing up for everybody if they dont use a filter.

Chris McFadden

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.

Christen Lorensen

I don't want to insult anybody, but I realy feal like the designers of jira/greeenhopper could benefit from reading "Design of everyday things" by Donald Norman

It ment as a fiendly tip.

John Garcia

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.

Christen Lorensen

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.

Aquarius

Agree with all options, we use custom select box field called "TEAM" that is must to fill (avoiding human factor problems).

HTH,

Aquarius.

Christen Lorensen

well thats not needed if you create a filter all members of the team with jql

assignee = xxx OR assignee = yyy OR assignee = zzz OR assignee = aaa OR assignee = bbb

which some people pointed out here allready.

SimonM

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?

Christen Lorensen

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)

Christen Lorensen

Ok so they kind people of atlassian made a ticket for adding an issue directly to a sprint from creation/edit view, please go vote for it: https://jira.atlassian.com/browse/GHS-7573

Lucid Software

Unless someone moves to another team. Then your history is messed up.

Pam

I would appreciate if someone can guide me on the specific steps of how to create the custom field and how to have sprints with two scrum teams run in parallel.

This is my first time using JIRA and I am really struggling with this.

Thanks

Annie_Baldwin

I have an issue where we have one sprint, two teams, so we have to "boards" - each board filters issues for only the members in that team. However, when I move to complete a sprint, the issues only get ported over for one of the teams. Ideas on how to fix this?

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software

board

sprint

parallel-sprints