Sprint Planning meeting in scaled scrum
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.
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?
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.
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.
> 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.
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.
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.
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?
Hi Rahul,
3.5 years later... can you please share you experience with this approach? Was it effective, or did you change it?
Thanks