1 project, 1 backlog, 3 sprints

Mariya Padalko2

Hello,

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?).

Thank you!

Nicolas Bourdages

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.

Cheers