Small teams can often out perform larger ones due to reduced communications overhead, reduced risk of interpersonal conflicts, and increased sense of overall ownership and accountability.
However, there are many ways to split the work in a large project between smaller teams.
One way is to divide the scope (the "what") of the project, another is to look at the solution approach or the skills required to perform certain activities (the "how" or the "who") and a third might be to combine these methods.
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
We had over eight Scrum teams, which we divided along product lines. That created a set of silos that stretched our Scrum of Scrums. It's hard to say if we would avoided the silos if we would have split the teams along epics.
...
1 reply by Kiron Bondale
May 13, 2022 3:38 PM
Kiron Bondale
...
Were the products interrelated such that one epic spanned multiple products?
We had over eight Scrum teams, which we divided along product lines. That created a set of silos that stretched our Scrum of Scrums. It's hard to say if we would avoided the silos if we would have split the teams along epics.
Were the products interrelated such that one epic spanned multiple products?
Kiron
...
1 reply by Stéphane Parent
May 13, 2022 6:10 PM
Stéphane Parent
...
Most of the epics spanned multiple Scrum teams, Kiron.
We had a client-facing application feeding into an internal benefits request management system which, in turn, fed the separate payment system.
On top of that we had other products that queried and manipulated the same data.
Because each product had its own technology stack, it meant little cross-training outside of a given Scrum team but a lot of back and forth to ensure features were appropriately carried through all the stacks.
Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
May 13, 2022 3:38 PM
Replying to Kiron Bondale
...
Were the products interrelated such that one epic spanned multiple products?
Kiron
Most of the epics spanned multiple Scrum teams, Kiron.
We had a client-facing application feeding into an internal benefits request management system which, in turn, fed the separate payment system.
On top of that we had other products that queried and manipulated the same data.
Because each product had its own technology stack, it meant little cross-training outside of a given Scrum team but a lot of back and forth to ensure features were appropriately carried through all the stacks.
...
2 replies by Do Diep Thao and Kiron Bondale
May 14, 2022 9:17 AM
Kiron Bondale
...
Very interesting - thanks for the clarification, Stephane! Given this, were the epics more than just "really big user stories" as they sound like they might have been used to represent whole subsystems?
Kiron
Apr 11, 2023 6:02 AM
Do Diep Thao
...
Hi Stéphane,
I am in the same boat with the scenario you described. We are trying to define a way to foresee availability of our developers to acquire more projects but sort of stuck on a good way to do so.
Mainly the difficulty is due to different technology stacks and the nature of our projects are creating prorotypes which can get very fluctuate and interchangeable for the product backlogs.
Do you mind sharing your experience?
Saving Changes...
Michael HilbertDirector of Project Management| TuWay CommunicationsBethlehem, Pa, United States
Our team likes to live in their own comfort zones and do well completing tasks using skills they enjoy and are good at. This seems to work well for most projects we are involved in. Saving Changes...
Most of the epics spanned multiple Scrum teams, Kiron.
We had a client-facing application feeding into an internal benefits request management system which, in turn, fed the separate payment system.
On top of that we had other products that queried and manipulated the same data.
Because each product had its own technology stack, it meant little cross-training outside of a given Scrum team but a lot of back and forth to ensure features were appropriately carried through all the stacks.
Very interesting - thanks for the clarification, Stephane! Given this, were the epics more than just "really big user stories" as they sound like they might have been used to represent whole subsystems?
Kiron
...
1 reply by Stéphane Parent
May 14, 2022 10:02 AM
Stéphane Parent
...
One epic for a specific client benefit would cover the capture of the client request, the processing of the request and the delivery of the benefit.
Such epics crossed many products and services.
Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
May 14, 2022 9:17 AM
Replying to Kiron Bondale
...
Very interesting - thanks for the clarification, Stephane! Given this, were the epics more than just "really big user stories" as they sound like they might have been used to represent whole subsystems?
Kiron
One epic for a specific client benefit would cover the capture of the client request, the processing of the request and the delivery of the benefit.
Such epics crossed many products and services. Saving Changes...
Most of the epics spanned multiple Scrum teams, Kiron.
We had a client-facing application feeding into an internal benefits request management system which, in turn, fed the separate payment system.
On top of that we had other products that queried and manipulated the same data.
Because each product had its own technology stack, it meant little cross-training outside of a given Scrum team but a lot of back and forth to ensure features were appropriately carried through all the stacks.
Hi Stéphane,
I am in the same boat with the scenario you described. We are trying to define a way to foresee availability of our developers to acquire more projects but sort of stuck on a good way to do so.
Mainly the difficulty is due to different technology stacks and the nature of our projects are creating prorotypes which can get very fluctuate and interchangeable for the product backlogs.
Do you mind sharing your experience?
...
1 reply by Stéphane Parent
Apr 11, 2023 12:57 PM
Stéphane Parent
...
If you have specific questions beyond want I've already shared, I'd be happy to answer, Do.
Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Apr 11, 2023 6:02 AM
Replying to Do Diep Thao
...
Hi Stéphane,
I am in the same boat with the scenario you described. We are trying to define a way to foresee availability of our developers to acquire more projects but sort of stuck on a good way to do so.
Mainly the difficulty is due to different technology stacks and the nature of our projects are creating prorotypes which can get very fluctuate and interchangeable for the product backlogs.
Do you mind sharing your experience?
If you have specific questions beyond want I've already shared, I'd be happy to answer, Do. Saving Changes...
