I work for a company who is developing one major new product, with three development teams building different aspects of that product. We would like to set up a sprint board per team, to which we will filter tickets from the central backlog. Our developers are spread between two time zones, so it is imperative that we use the simplest method in tracking our development.
The bit of research I did showed that this will be possible if we allow 'Parallel Sprints': https://confluence.atlassian.com/display/AGILE/JIRA+Agile+Labs
If we do enable Parallel Sprints, does that mean that the three development teams will have to maintain an identical sprint schedule? Meaning sprints between the three teams will all end/start at the same time?
Additionally, if there is a smarter way to go about developing one product between three teams using the Agile method - I'm all ears (eyes?).
Although you say you're setting up Kanban boards, I'm going to assume you meant scrum boards, since Kanban doesn't use sprints.
Sprints have start and end dates that are completely independent from other sprints when you have Parallel enabled. On team could be working on 3-week sprints, and another on 2-week. There's no restriction on this.
I really don't think you should use different schedules however, just so you don't end up needing the other team because you're in the middle of your sprint, but they're unavailable because they're in planning or something.
I presume each of your teams is responsible for a different component of the product, so make sure your issues are well-labeled with these components, so the correct issues end up in the right sprints.
Also, even though your teams are in different time zones, try as much as possible to have daily meetings with people from all teams attending remotely, a "scrum of scrums" if you will. Last thing you want is to fall out of sync, and have your product owner out of touch with the work being done in the locations he's not.
Lastly, Agile development is a vast subject. No two implementations are completely alike because no two teams or products are completely alike. I suggest you keep informed on Agile practices and encourage your teams to read on the subject, watch videos, get training etc. With solid knowledge of the methods, your teams can make the tool work in the way that makes sense to your situation.
I really appreciate you taking the time to explain this! Apologies for not clarifying sufficiently: You are correct, we are not using Kanban. Our sprint schedule (including scrum meetings, planning meetings, etc.) is going to be universal across the three teams for the entire duration of the product's development so that coordination will be seamless and everyone knows what to expect and when to expect it. Basically I am trying to figure out what the best way to create three unique sprints from one "master" project is (if that is possible) in Jira.
Oh yes. We create multiple sprints all the time. In fact, we have 2 boards that contain issues from the same set 120 projects. Each board have a different naming convention for sprints. That allows us to do this: Board A sees all issues, except those that have a sprint from board B, and board B sees all issues, except those from a sprint from board A. That way, each board has its own sprints and there's no overlap. See the query: "Project in (projectMatch("^Games")) AND (Sprint != Delivery OR Sprint is EMPTY) ORDER BY Rank ASC" So you see, the filter picks up all projects that start by Games (the projectMatch function comes with the free Scriptrunner plugin, which I strongly recommend), and only issues that have a sprint that doesn't contain "Delivery" in its name, or issues that have no sprint.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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