I'm looking for ways to manage several teams working on the same project, with several "Views" to the same backlog (and I would like to do this in Jira+Greenhopper).
The following article makes a number of suggestions, but they seem to be outdated (or I don't see how they apply): https://jaibeermalik.wordpress.com/2010/07/22/using-greenhopper-to-manage-multiple-teams-in-agile/
I've tried setting up a single board with less filters, and then two more-filtered boards, and that makes it easy to manage the "Team 1 backlog" vs "Team 2 backlog" vs "Complete backlog", in the "Plan" view, but as soon as I create a sprint this seems to fall apart.
In Greenhopper 6 (it's all I've used, I can't comment on earlier releases) greenhopper seems to be set to assume that there is only one Sprint running at a time (which makes sense, for a single team), so that's where my "filtering" idea breaks down.
I've also considered setting up multiple projects (I assume that you can have at least one sprint running per project), but the problem then is that moving issues between teams' backlog becomes hard (or impossible?), as Issue Identifiers implicitly contain the project abbreviation.
Is there any way, with Greenhopper, to have multiple teams sharing an overall backlog with their own views, in such a way that issues can be moved from one team to the other if/when necessary (before they are included in a sprint, of course)?
Turns out my test case was too complicated.
Greehopper has no problems with multiple "Boards", with different filters, running sprints in parallel, within the same project.
What made it refuse, in my case, was that my filter was showing a particular issue in both boards, and therefore that issue was showing up on an in-progress sprint even on the board of the team where I wanted to start another sprint.
Bottom line: as long as the filters on your boards are mutually exclusive, it will work just fine!
(in fact, it's even nicer than that - if you do start two sprints in parallel on separate mutually exclusive boards, then any "overarching" boards will show you all the sprints that are in play according to that board's filters. Similarly, the reporting seems to show you data for issues that match the filters of your Board - even if those are a superset or subset of other boards. It's really rather lovely! :) )
UPDATE: I originally used "Label" as the basis for the filtering, but this was a problem for a Scrum workflow because the technical tasks (created during sprint kickoff) didn't inherit this field automatically; the "Component" field, on the other hand, is inherited by default so is a much better choice.
UPDATE - PROBLEM WITH THIS FLOW (Temporary, hopefully): The latest version of Jira Agile breaks the flow above, because it allows the "Start Sprint" feature to include stories that were included in the sprint in some higher-level planning board, without the knowledge of the team that IS actually starting the sprint. Those invisible stories then show up in that team's sprint, gunking things up on all levels (reporting, etc) and can't be cleanly resolved, as they show up in the committed numbers of that sprint.
Hi Christen, you've asked your question as an answer - not sure anyone here cares, but I'd recommend that you either add a comment to the previous answer or ask a separate question. Moving on to the substance of your question: Each Team would have their own board, with their own board filter; the different teams' board filters must be mutually exclusive, so that each team sees only its own issues/sprints in its board; You can then have a general board, with less-specific filters, on which all the issues (and sprints) appear together. In this way you have team-specific backlogs/boards and a "general" backlog/board that provides an overview.
The question was if I understood this solution correctly, by explaining how I understood it. And you answered it with the same solution, so yes I understood it correctly.
I am searching for an answer to a similar problem. This question might have entailed clues to this.
Hi Robert, looks like this should be a "comment" rather than an "answer", but in any case: With the setup I described above each team has its own "Board" in greenhopper, and each "board" has its own reporting section - each team has its own velocity reporting, burndown, etc. The sprints are associated to the team-specific Boards.
If I understand correctly, there's a single backlog, with multiple teams (represented by separate boards) drawing from the backlog. Can you explain the story heirarchy here? My experience with JIRA/GH is telling me that a story on a board can only be parented to an Epic in the same board - for Epics that span multiple teams (which is certainly the norm for multiple teams on the same project), that seems to disallow creating an Epic that encompasses work from multiple teams.
and apologies in advance if I've commented when I should have answered or vice versa... I'm trying to get to an answer or best practice for board, epic/story heirarchy and usage...
Hi Peter, the way I'm handling this is using the "Component" field; as I noted above, you need your board filter to be based on a field that gets inherited on subtasks, so that your subtasks automatically end up in the same board as their main story - in my case, I'm using "Component". To address this "share across boards" notion, then, I have a component "Team1", another "Team2", and a third "AllTeams". My board filter for the Team 1 Board shows all issues that have component Team1 OR AllTeams. On the Team 2 Board, the filter is Team2 OR AllTeams. Epics that are to be shared by 2 teams get component "AllTeams", whereas most stories and some epics get a team-specific component. Sometimes a story will temporarily get component "AllTeams" when I haven't decided which team will get it yet, and I want both to temporarily be aware of it (before it gets included in a sprint of course). Hth.
@Peter Dittman (re: team-specific data): team-specific data is in the Reports section of that Team's board.
@Christen Lorensen (re: quick filter): The problem with having your boards filtering by assignee is that you need to have all your stories pre-assigned to specific people; I'm assigning to Teams (with the "Component" field), but not to specific individuals. The teams allocate stories and subtasks internally.
@Peter (re: filters): The "Board Filter" does work on reports - each board gets its own set of reports, driven by the stories/issues that are matched by that board's filter.
@Christen (re: component): yes, you get separate reports for each board, and I have my different boards include different stories by filtering on the stories' (issues') "Component" values.
The burndown report is within the board, and runs from the data of the stories in that board; the list of stories in that board is driven by the board filter. there is no problem there (unless you're talking about some other report than the "Burndown Chart" in the "Report" section of your target Board, in the "Agile" menu?). The only thing I'd be careful to watch out for is making sure that your board filters are mutually exclusive (you can't have one story in two different sprints at the same time, for obvious reasons); this is especially easy to get wrong with subtasks, as they only inherit some properties from the parent issues/stories automatically.
I admire the power of GH wrt multiple board support, especially the possibility to have the cumulative board. One thing I am missing is cumulative reports - reports aggregating info from multiple boards.
The initial reason for my post is regarding team boards. I am not so sure these should be team boards. There are 3 dimensions one can divide the product backlog: per Team, per Product Owner or per Goal. After initial thinking I became a strong supporter of dividing the backlog per Goal. After all we are interested to keep track progress on goals and forecast goal completion based on velocity on that particular goal.
Very interested to hear your comments!
Find more detailed information for handling multiple teams on a single project,
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
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!
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