Regarding Multiple teams on Same Product, Product backlog

Hi Santosh,

I think, the different teams can have their own Sprint timelines. The most important thing is to synchronize with the Product Owner as he has to time the releases. If they agree to have a different timeline than other Development Teams, that's ok.

Yet, there could be advantages in having the same Sprint timelines, perhaps if people have to change between Development Teams and it's probably easier for the Product Owner to keep the overview.

Hi Anke,

Thanks for the clarification. Your message has given some idea now.

regards.
Santosh.

Also remember that the increment at the end of each sprint, for each team, has to be fully integrated and releasable. That fully integrated release has to be shown at the Sprint Review.

While using different Sprint lengths is not against Scrum per se, I've rarely seen it work well in practice. I would want to know the reason/ROI behind why a different sprint length for teams working on same product is perceived to be better.

> does they have the flexibility to plan their own sprint being a different team. 

They do have that flexibility. However teams also have a duty to optimize product qualities including the timeliness of delivery, and to minimize waste.

If sprint deliverables for the same product are not synchronized, then this implies that one or more outputs will be put in delay and that a depreciation in value will be incurred.

Unsynchronized sprints often arise through resource contention. For example, if a Product Owner cannot attend the reviews or retrospectives of multiple teams because they clash, then those teams may be tempted to stagger their sprints at least slightly. Contention for meeting rooms at sprint boundaries is another common problem. These resourcing issues are not insurmountable and they typically indicate a need for better agile sponsorship and release management.

Thanks Charles and Ian for insights.

By which,
I see that it's not a good Practise to have different sprint timelines for different teams working on the same product.
And scrum will not restrict you though if you have one.

One more:

I also learnt that integration should be done and submitted in sprint review by above explanation by Charles.