So we have several teams working along side each other and each team own their Epics and stories. There is no overlap in terms of Epics/Stories between teams.
Question 1: do you create one sprint across all teams or do you create a sprint per team (i.e. per board)? I've seen multiple sprints for each board but honestly I don't see the benefit of it.
Question 2: how do you set up your boards so that issues are mutually exclusive? I mean JIRA doesn't provide a "team" field as such and add-ons such as advanced roadmaps are not really an option for us.
Any other best practices you'd recommend for an essential SAFe set up?
1. You treat a board as though it is a team effectively. As part of a scaled setup, you then would have one sprint per board, with all of your teams having the same sprint cadence (the usual example is everyone would start their sprint on day X and it will last 2 weeks)
2. You put data on the issues that enables you to separate them exclusively. The easiest one, and the one Jira tends to default to is simply "project = X" - you have one sprint board per project. But if you're using project to delineate something else, then you would look to use something else - an easy and obvious one would be to set up a custom field of a single-select type and name each team in there, then a board can select for each team. Or use a group picker (which gives you a bit more cleverness in permissions, reporting and searching, but does need you to be on top of group management, the right people must be in the right groups)
thanks @Nic Brough _Adaptavist_
So at the moment I have a single project and all Epics and stories across all teams are in there. I have 4 boards but at the moment we are just managing them using labels which is not ideal i.e. if it's team 1 with label the epic or story as team1.
So you're suggesting for team1, I should create a team1-sprint1 and for team2 I should create a team2-sprint2? is this required for burndowns? It looks like JIRA is unable to produce the burndown if I create just one Sprint1 across all teams and just assign different issues depending on which team owns the Epic.
Background When you hear the words ‘Release notes’, almost always you think of an unsolicited email from a software vendor. But I am here to tell you that from our data, sending release notes via E...
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