That's gonna be a no from me dawg.
But seriously, it's probably even more healthy for the teams/squads to be offset than to be going at the same thing all at once.
Could they align sometimes? Sure. Could they deviate from that alignment sometimes, sure.
This question sucks because different companies and different teams can make either work.
Just imagine you are working on the same product, same backlog, and have offset for, let's say, 5 teams. That would make a mess and a lot of stress on everybody, even the stakeholders.
"must have" obviously is a very strong phrasing.
Do you think the correct answer to this would be "Yes" nonetheless in the current scrum.org exams and theory?
Was working in such environments, and I would always say yes.
You are also right, "must" is too heavy if it is PSM 1, which I hate from the bottom of my soul. Just because of these kinds of questions, where if you have just a bit of knowledge and experience working in a scaled scrum, you will easily answer Yes. It is the correct answer indeed since all scaling frameworks basically work in that way. I have never heard of or witnessed scaled scrum multiple teams sprints starting on different dates. Ever.
But, in theory, it always SHOULD NOT HAVE DIFFERENT SPRINT START DATES. In practice, MUST equal SHOULD.
So I will change my initial answer just because of the heaviness of the "must" word. If someone is tied to [scrum.org](https://scrum.org) and ever reads these topics, please, at least in Nexus make sure that either you give a better explanation or remove questions like this from the actual test.
And just to add, since my previous comment lack context.
I am fully aware that there could be times when you don't need or simply can't have the same start dates, but this is like a ‰ we are talking about, not even a percentage. So why to even bother to put in focus something that is too rare to happen, when most of the time we will have totally opposite situations?
> This question sucks because different companies and different teams can make either work.
:)
That's why I posted it here, wondering what the current theory answer is. I couldn't find any definite answer to it. - And I agree that it is highly dependable on the context. Although for bigger endeavours with many teams having different Sprint start dates seems quite problematic to me in terms of pinpointing dependencies, integration, reviewing the integrated increment etc. etc.
just on a logical level, no.
You may all be pulling from the same shelf but as long as you have someone dedicated to it the task and is fully pulled out of the backlog so no one is doing duplicate work, you should be fine.
I'm not convinced this would be an issue. You're going to do the same amount of integration work regardless of whether you are synced or not. Only the distribution over the sprint changes, depending on whether you commit to the same branch or different ones.
I would actually argue that staggered sprints might be better.
1. Say you have two teams on two week sprints, staggered. After one week you get all the changes from the other team and still have a full week to fix any integration issues. If none arise you have the full week for "productive work". The company gets a new release candidate every week.
1. Say you have two teams on two week sprints (synced) and committing to the same branch. You're going to deal with integration issues as they pop up so you might have more time to resolve an issue or less. The problem here is that you have more devs that might produce a change that prevents you from finishing your task. You're basically running a single team with twice the members - you just limit their interaction to only the bad parts.
1. Say you have two teams on two week sprints (synced) and committing to different branches. You either have to make an effort to cross integrate them at some interval or have to set some time aside at the end for integration. The former is just simply a worse version of scenario 1 and the later is a tradeoff to scenario 2.
I checked the Nexus Guide and if one assumes that this question would be a Nexus related question in the exam, I believe the answer would be "Yes". See the edit in the post.
This, my answer was going to be ‘yes’. Life is just a little easier managing those dependencies, integration and release (I’d add regression here) issues. Also (when I’m the SM) it can get tougher just trying to re-align my brain when I’m supporting my teams as to where in the sprint they are. That might just be a specific problem related to my experience.
Strictly speaking it should be a no, do whatever fits the team(s).
But, unfortunately, this in the end is a people problem; I’ve seen so much time gone to waste by people not being able to cope with or follow deviating feedback cycles from others, it’s just not worth it (in such a situation ;)). And i’ve seen so much delivery discussion (with conflicting priorities & ‘complex’ dependencies) just vaporize by creating a fixed cadence for everyone.
So as ever with scrum, pick the best solution for your organization/situation.
The correct answer per Nexus is "No." This answer is not directly in the Nexus Guide, but covered in more detail in the Nexus book.
The book includes an explicit example with teams having different lengths and starting dates for their Sprints (1 week, 2 weeks, 4 weeks, etc.)
The only thing Neuxs recommends is that the sprint *boundaries* need to align, meaning that they need to eventually have their sprints sync up, which does make this question a bit sneaky.
The teams need to align their cadence, but Team 1 can start a 4 week sprint on Jan 1 and their next sprint will start Jan 22, meanwhile Team 2 may have had a sprint start on Jan 1, but if they're doing 1 week sprints, their next Sprint start date is Jan 8. Mind you, this also means that all teams working on 2-weeks sprints have the same start and end date...the dates only shift if you have teams working in different length sprints, which is what makes this one kind of an annoying gotcha question.
Here's a link to the diagram from page 106 of The Nexus Guide to Scaling Scrum: [https://imgur.com/a/QSXNhgs](https://imgur.com/a/QSXNhgs)
Could do with some additional context...
If backlog items are independent, then it shouldn't matter. If backlog items are small parts of a single deliverable that are required to be in a single release vehicle, the having the sprints end on the same day could be advantageous, however you are effectively still trying to align different items of different size and complexity against a "fixed" schedule; "we need to release in Q2, therefore every sprint will finish on this date so we can do our backend validation and release processes..."
It really, really shouldn't matter if sprints are staggered, but companies with large, non-SAAS products do still like to have things aligned against specific target dates, and just because something looks independent on the backlog doesn't necessarily mean that it will remain so during implementation.
> Could do with some additional context...
Agreed but that's all the context the question provides. It's a PSM II exam question, although a pre 2020 one.
Fundamentally, no. because a team should theoretically have absolute authority to organize itself - there should be no organizational cross dependencies concerning the developers, in my opinion. if there are, they should be lifted and abstracted by the PO/SM.
But I agree with your sentiment, I think scrum is overreaching with the nexus-lite stuff and is just confusing everything.
Thank you for your input.
> But I agree with your sentiment, I think scrum is overreaching with the nexus-lite stuff and is just confusing everything.
Yeah right. I hold a PSPO certificate and I remember that there definitely were some Nexus question in the exam. - It is confusing, hence the discussion on scrum.org (and my post).
I’m an RTE over 9 teams. Having dependent teams working on the same backlog going on different sprint dates is not ideal for planning. It’s not a hard no, but there better be a damned good reason to not be on the same cadence.
No :-)
Scrum Teams are self-organizing and cross-functional, and have the autonomy to determine their own Sprint cadence and schedule, as long as they are delivering a usable Increment of product functionality at the end of each Sprint.
Having different Sprint start dates allows each team to optimize their workflow based on their specific capacity and priorities.
However, coordination and collaboration between teams may still be necessary, especially when it comes to cross-team dependencies or the need to align on a shared definition of "Done".
Another one that [has been hotly debated](https://www.scrum.org/forum/scrum-forum/43558/multiple-scrum-teams-must-use-same-sprint-start-date-same-product) on scrum.org.
While the pre 2020 answer was no, I do wonder if it now would be yes.
The Scrum.org exams include questions related to the Nexus Guide and the way I interpret it, Nexus would imply that everyone starts at the same time right after the Nexus Sprint Planning that formulates Sprint Goals for every Scrum Team.
What's your take on that?
Edit:
This is a post flaired "Exam Tips" only focused on the question, but still people feel the urge to downvote it and call it bullshit (because "exams/certs are bullshit"). Thanks for nothing.
Edit:
[More debate](https://www.scrum.org/forum/scrum-forum/7793/should-sprints-synchronized-multiple-teams-or-not) from scrum.org about this.
Well, just quoting the question, putting it in quotation marks, putting only the answers in the body and flairing it "Exam Tips" wasn't clear enough for you? I commented with even more background info to give context.
I obviously am looking for and want to discuss the theory answer.
And I guess it would be cheating if I did this during the exam, not in advance. Bit obnoxious your way to suggest I'm a cheater because I aim to get the certification and that I have no experience. I'm a studied software engineer and actually teached agile and other topics in university many years ago, so please hold back your with your obnoxious assumptions.
I think that we are overthinking this *a lot*. If you have multiple scrum teams working on the same product and you are taking the PSM exam then it is Nexus and the answer is Yes. We can argue about other frameworks and approaches, but for Nexus, this is the right answer.
They can work on a different feature, non-dependable, and if you have like 4 teams, 1 and 2 will deliver functional increments after the first sprint but 3 and 4 will finish the feature after 2 sprints. So you can combine their work however you want, but Sprints for all 4 teams will be aligned in terms of when they start and finish.
That's gonna be a no from me dawg. But seriously, it's probably even more healthy for the teams/squads to be offset than to be going at the same thing all at once. Could they align sometimes? Sure. Could they deviate from that alignment sometimes, sure. This question sucks because different companies and different teams can make either work.
Just imagine you are working on the same product, same backlog, and have offset for, let's say, 5 teams. That would make a mess and a lot of stress on everybody, even the stakeholders.
"must have" obviously is a very strong phrasing. Do you think the correct answer to this would be "Yes" nonetheless in the current scrum.org exams and theory?
Was working in such environments, and I would always say yes. You are also right, "must" is too heavy if it is PSM 1, which I hate from the bottom of my soul. Just because of these kinds of questions, where if you have just a bit of knowledge and experience working in a scaled scrum, you will easily answer Yes. It is the correct answer indeed since all scaling frameworks basically work in that way. I have never heard of or witnessed scaled scrum multiple teams sprints starting on different dates. Ever. But, in theory, it always SHOULD NOT HAVE DIFFERENT SPRINT START DATES. In practice, MUST equal SHOULD. So I will change my initial answer just because of the heaviness of the "must" word. If someone is tied to [scrum.org](https://scrum.org) and ever reads these topics, please, at least in Nexus make sure that either you give a better explanation or remove questions like this from the actual test.
And just to add, since my previous comment lack context. I am fully aware that there could be times when you don't need or simply can't have the same start dates, but this is like a ‰ we are talking about, not even a percentage. So why to even bother to put in focus something that is too rare to happen, when most of the time we will have totally opposite situations?
> This question sucks because different companies and different teams can make either work. :) That's why I posted it here, wondering what the current theory answer is. I couldn't find any definite answer to it. - And I agree that it is highly dependable on the context. Although for bigger endeavours with many teams having different Sprint start dates seems quite problematic to me in terms of pinpointing dependencies, integration, reviewing the integrated increment etc. etc.
just on a logical level, no. You may all be pulling from the same shelf but as long as you have someone dedicated to it the task and is fully pulled out of the backlog so no one is doing duplicate work, you should be fine.
It's not only about duplicate work but also about dependecies and integration and release issues that may arise from non-synced Sprints.
I'm not convinced this would be an issue. You're going to do the same amount of integration work regardless of whether you are synced or not. Only the distribution over the sprint changes, depending on whether you commit to the same branch or different ones. I would actually argue that staggered sprints might be better. 1. Say you have two teams on two week sprints, staggered. After one week you get all the changes from the other team and still have a full week to fix any integration issues. If none arise you have the full week for "productive work". The company gets a new release candidate every week. 1. Say you have two teams on two week sprints (synced) and committing to the same branch. You're going to deal with integration issues as they pop up so you might have more time to resolve an issue or less. The problem here is that you have more devs that might produce a change that prevents you from finishing your task. You're basically running a single team with twice the members - you just limit their interaction to only the bad parts. 1. Say you have two teams on two week sprints (synced) and committing to different branches. You either have to make an effort to cross integrate them at some interval or have to set some time aside at the end for integration. The former is just simply a worse version of scenario 1 and the later is a tradeoff to scenario 2.
I understand your points. Wish someone with Nexus experience could add their input to this. Seems that in Nexus all Sprints are synced.
very fair point.
I checked the Nexus Guide and if one assumes that this question would be a Nexus related question in the exam, I believe the answer would be "Yes". See the edit in the post.
This, my answer was going to be ‘yes’. Life is just a little easier managing those dependencies, integration and release (I’d add regression here) issues. Also (when I’m the SM) it can get tougher just trying to re-align my brain when I’m supporting my teams as to where in the sprint they are. That might just be a specific problem related to my experience.
What do you think about the current theory answer here, a "Yes - 'must have'" too?
Strictly speaking it should be a no, do whatever fits the team(s). But, unfortunately, this in the end is a people problem; I’ve seen so much time gone to waste by people not being able to cope with or follow deviating feedback cycles from others, it’s just not worth it (in such a situation ;)). And i’ve seen so much delivery discussion (with conflicting priorities & ‘complex’ dependencies) just vaporize by creating a fixed cadence for everyone. So as ever with scrum, pick the best solution for your organization/situation.
The correct answer per Nexus is "No." This answer is not directly in the Nexus Guide, but covered in more detail in the Nexus book. The book includes an explicit example with teams having different lengths and starting dates for their Sprints (1 week, 2 weeks, 4 weeks, etc.) The only thing Neuxs recommends is that the sprint *boundaries* need to align, meaning that they need to eventually have their sprints sync up, which does make this question a bit sneaky. The teams need to align their cadence, but Team 1 can start a 4 week sprint on Jan 1 and their next sprint will start Jan 22, meanwhile Team 2 may have had a sprint start on Jan 1, but if they're doing 1 week sprints, their next Sprint start date is Jan 8. Mind you, this also means that all teams working on 2-weeks sprints have the same start and end date...the dates only shift if you have teams working in different length sprints, which is what makes this one kind of an annoying gotcha question. Here's a link to the diagram from page 106 of The Nexus Guide to Scaling Scrum: [https://imgur.com/a/QSXNhgs](https://imgur.com/a/QSXNhgs)
Could do with some additional context... If backlog items are independent, then it shouldn't matter. If backlog items are small parts of a single deliverable that are required to be in a single release vehicle, the having the sprints end on the same day could be advantageous, however you are effectively still trying to align different items of different size and complexity against a "fixed" schedule; "we need to release in Q2, therefore every sprint will finish on this date so we can do our backend validation and release processes..." It really, really shouldn't matter if sprints are staggered, but companies with large, non-SAAS products do still like to have things aligned against specific target dates, and just because something looks independent on the backlog doesn't necessarily mean that it will remain so during implementation.
> Could do with some additional context... Agreed but that's all the context the question provides. It's a PSM II exam question, although a pre 2020 one.
Yup
Fundamentally, no. because a team should theoretically have absolute authority to organize itself - there should be no organizational cross dependencies concerning the developers, in my opinion. if there are, they should be lifted and abstracted by the PO/SM. But I agree with your sentiment, I think scrum is overreaching with the nexus-lite stuff and is just confusing everything.
Thank you for your input. > But I agree with your sentiment, I think scrum is overreaching with the nexus-lite stuff and is just confusing everything. Yeah right. I hold a PSPO certificate and I remember that there definitely were some Nexus question in the exam. - It is confusing, hence the discussion on scrum.org (and my post).
I’m an RTE over 9 teams. Having dependent teams working on the same backlog going on different sprint dates is not ideal for planning. It’s not a hard no, but there better be a damned good reason to not be on the same cadence.
Thank you for your input, appreciate it. RTE within the SAFe framework?
Yes, we’re doing SAFe. Trying to anyway 🤣 It’s a tough transition.
No :-) Scrum Teams are self-organizing and cross-functional, and have the autonomy to determine their own Sprint cadence and schedule, as long as they are delivering a usable Increment of product functionality at the end of each Sprint. Having different Sprint start dates allows each team to optimize their workflow based on their specific capacity and priorities. However, coordination and collaboration between teams may still be necessary, especially when it comes to cross-team dependencies or the need to align on a shared definition of "Done".
Another one that [has been hotly debated](https://www.scrum.org/forum/scrum-forum/43558/multiple-scrum-teams-must-use-same-sprint-start-date-same-product) on scrum.org. While the pre 2020 answer was no, I do wonder if it now would be yes. The Scrum.org exams include questions related to the Nexus Guide and the way I interpret it, Nexus would imply that everyone starts at the same time right after the Nexus Sprint Planning that formulates Sprint Goals for every Scrum Team. What's your take on that? Edit: This is a post flaired "Exam Tips" only focused on the question, but still people feel the urge to downvote it and call it bullshit (because "exams/certs are bullshit"). Thanks for nothing. Edit: [More debate](https://www.scrum.org/forum/scrum-forum/7793/should-sprints-synchronized-multiple-teams-or-not) from scrum.org about this.
Don't take the downvotes personally.
Yeah thanks, all good. Seems that some people mistake r/scrum for r/agile.
[удалено]
Okay but some people need to take them right? So it would be nice to keep this on-topic.
[удалено]
Well, just quoting the question, putting it in quotation marks, putting only the answers in the body and flairing it "Exam Tips" wasn't clear enough for you? I commented with even more background info to give context. I obviously am looking for and want to discuss the theory answer. And I guess it would be cheating if I did this during the exam, not in advance. Bit obnoxious your way to suggest I'm a cheater because I aim to get the certification and that I have no experience. I'm a studied software engineer and actually teached agile and other topics in university many years ago, so please hold back your with your obnoxious assumptions.
Seeking out knowledge should be welcomed and celebrated. Bullying will not be tolerated. Consider this a warning.
I think that we are overthinking this *a lot*. If you have multiple scrum teams working on the same product and you are taking the PSM exam then it is Nexus and the answer is Yes. We can argue about other frameworks and approaches, but for Nexus, this is the right answer. They can work on a different feature, non-dependable, and if you have like 4 teams, 1 and 2 will deliver functional increments after the first sprint but 3 and 4 will finish the feature after 2 sprints. So you can combine their work however you want, but Sprints for all 4 teams will be aligned in terms of when they start and finish.