Regarding Multiple teams on Same Product, Product backlog

Last post 12:01 pm November 10, 2014
by santosh kommula
5 replies
Author
Messages
11:51 am November 6, 2014

Regarding multiple teams working on same product, Scrum Guide says that they often does.

And one Product backlog is used to describe the work on the product.

Does they have to share the same Sprint timelines from start to finish to synchronize the increment or does they have the flexibility to plan their own sprint being a different team.

thanks,
Santosh

07:38 am November 7, 2014

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.

12:35 pm November 7, 2014

Hi Anke,

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

regards.
Santosh.

01:54 pm November 7, 2014

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.

04:35 pm November 7, 2014

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

10:38 pm November 7, 2014

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.