Scaling up personnel ( adding/removing) in multiple scrum teams under a single portfolio
Hi All,
Would like to have some insights on the below scenario from the SM community here :-
1) I am supporting a portfolio manager who has multiple scrum teams rolling up to him as a Scrum Master.
2) Portfolio is linked with a certain famous low-code/no-code workflow platform which offers platform as a service strategy to the organisation.
3) Each scrum team is linked to a certain application/topic area linked to the above platform and has its own set of Product Owners who own the product roadmap of their specific applications and are dependent on this platform
4) Each scrum team delivers increments that may be independent from others but some may also have dependencies on other scrum teams to deliver the increment.
5) In addition to the individual product backlogs for the above mentioned scrum teams, there is independent demand for new services coming in that do not have a defined "home-base" in one of the above mentioned backlogs. These are complex demands and may need on an average a 3-4 month engagement for a cross functional scrum team to get it resolved.
6) There is a defined demand management process in the organisation which helps in identifying such adhoc demands coming in that do not have a natural homebase in one of the above mentioned backlogs.
In the above scenario, will it help to have a common estimation methodology across all scrum teams? The portfolio manager needs a portfolio level capacity planning concept in place that will help him in taking fact based decisions on scaling up/scaling down people in individual scrum teams or form new custom scrum teams based on need/demand - what will be your recommendations in the above scenario? I know we do not encourage time based story point estimations but in this case time based estimations makes this easier, would like to understand if there is a better way of doing this.
Ideas/suggestions on the above problem scenario are welcome. Looking forward to hearing from all of you!
In the above scenario, will it help to have a common estimation methodology across all scrum teams?
It seems unlikely, because the teams are working on different products with different product backlogs. They would therefore have little reason to normalize an estimation approach. Remember that the purpose of estimation is to help teams to get their arms around how much work they can take on in a Sprint: everything else reduces to value delivery and empirical process control.
The portfolio manager needs a portfolio level capacity planning concept in place that will help him in taking fact based decisions on scaling up/scaling down people in individual scrum teams or form new custom scrum teams based on need/demand
Why would he make these decisions? Shouldn't the teams be encouraged to self-manage, and to anticipate their own needs based on the evidence they gather for themselves?
Hi Ian, thanks for your response. Let me elaborate a bit further - all the above scrum teams are develop products around the same application and come under the same portfolio and cost centre. They have some amount of dependencies on each other. There is a certain fixed budget for this portfolio and there is a fixed common resource pool that needs to be leveraged whose numbers can’t be increased so scaling of resources in one scrum team will come in at the cost of the other. There is a strong need for a portfolio level resource planning - need to figure out how best to manage it in the agile world!! Need suggestions if anyone has encountered the same.
Each scrum team should have their own SM, so why is the portfolio manager the SM?
Why doe the scrum teams have their own set of Product Owners? Each team should only have one PO. A single PO could be part of multiple teams and be responsible for multiple products if they have the capacity to do so.
As Ian has already stated, each team should be making their own estimates, as only they know their current capacity.
Each scrum team delivers increments that may be independent from others but some may also have dependencies on other scrum teams to deliver the increment.
scrum teams are develop products around the same application
The above two statements indicate that the application should be classed as the product, in which case you could look into seeing if Nexus would help.
The portfolio manager needs a portfolio level capacity planning concept in place that will help him in taking fact based decisions on scaling up/scaling down people in individual scrum teams or form new custom scrum teams based on need/demand
There is a certain fixed budget for this portfolio and there is a fixed common resource pool that needs to be leveraged whose numbers can’t be increased so scaling of resources in one scrum team will come in at the cost of the other
In my interpretation, the above 2 problem statements contradicting to each other. If you have fixed budget for teams then is it not that team prioritise the work for that available capacity ?
need to figure out how best to manage it in the agile world!!
In the iron triangle representation, For agile way of working the cost(the team) and time(sprint length) is constant, scope is flexible. The team chooses the priority scope for each sprint. In scaled approach, there is Quarterly plannings to discuss scope at portfolio level.
When it comes to adhoc works like production tickets or dependencies from other teams, there is some capacity allocated in the team for every sprint.