Skip to main content

Sprint Planning meeting in scaled scrum

Last post 02:16 pm August 14, 2018 by Tudor Bastea
8 replies
12:55 am January 13, 2015

Hi All,

I want to know the opinions for scrum masters about the Sprint planning meeting in scaled scrum.
In my organization we have 4 scrum teams working together on one product (as of now work is independent of each other but soon work will be interdependent).

My Question is the sprint planning session should be done with all teams at a time or it should be separate session for individual team.

I am looking your experience before making a final call.


03:47 pm January 13, 2015

If the teams are currently working independently of each other, how is their work being integrated into potentially releasable increments of the product?

Are the 4 teams actually drawing work from the same Product Backlog, and do they have the same Product Owner?


05:25 am January 14, 2015

Teams are working on same product but the modules are independent hence integration is not an issue as of now. and the Product backlog is maintained by group of Product owners but they represent as a one Product owner.
We have Scrum Scrum event planned weekly basis to check the inter dependencies if any and till so far it worked well.
But i can imagine the situation when stories assigned to teams are dependent of each other. We have continuous integration system in place which make sure integration.

My original questions is whether to have a sprint planning together with all teams or it should be individual.

The solution i proposed to my teams and product owners is to divide the session in two parts where first part will include all teams and PO will go over all the stories at high level. Then in second session respected PO will work with individual teams to detail the stories.

if you have any better suggestion please let me know.


08:20 am January 15, 2015

Hi Rahul,
I wonder how modules of the same product can ever be independent.
However, the Scaling Scrum approach is to have the planning together with all teams.
This holds up the principle of self organization and enables the teams to resolve dependencies.
Self organization also means that if the teams want to split the planning into two parts, go for it.
Inspect how it works, and adapt.
I once had two teams which wanted to split it like you proposed, so we did it and it worked well for them, so we kept it that way.


10:23 am January 15, 2015

> I wonder how modules of the same product can ever be independent

I think that's the issue that needs addressing first. It sounds as though modules are not being integrated into end-of-sprint increments of potentially shippable product. Also, we've been told that the "the Product backlog is maintained by group of Product owners". That sounds a bit too close to product ownership by committee.

Perhaps I'm being too cynical and I'm reading too many problems into this situation. However, I wouldn't advise scaling Scrum from a baseline implementation which has these question marks around it.


11:09 am January 15, 2015

We definitely recommend having all teams for a single product plan each Sprint together. In addition to self-organization, clarification with a single product owner is feasible if everyone is together at once. This can be challenging with remote team members but current video conferencing technology helps.


12:57 am January 16, 2015

Thanks a lot for your replies.

The suggestion I gave was accepted by teams and I will Monitor the effectiveness of it.

The modules are independent of each other in respect of nature of work these teams doing. Like we have database and stored procedure, services ,UI applications. Teams are tuning these applications for performance, security issues etc. The functionality of system remains as it is. The input and output of every program is unchanged. Hence it is independent.


07:49 am January 28, 2015

So let's talk about benefits you might get if you let the teams talk with each other. Right now the UI team thinks about ways to make the UI faster, and the services team thinks about ways to make the services faster.
Do you think there might be issues which involve both teams?
For instance, a UI response is very slow, because the UI sends many calls to services. The UI team thinks: We cannot fix this, because there is no other service. The services team thinks: Our services are very fast already. What if the services team provided one service for the needed functionality, which the UI team could call?


11:56 am August 14, 2018

Hi Rahul,

3.5 years later... can you please share you experience with this approach? Was it effective, or did you change it?

Thanks


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.