Skip to main content

How do you know when you need to scale up resource vs seeking to challenge value and prioritisation

Last post 12:15 pm November 24, 2022 by Ryan Kent
4 replies
11:37 am November 16, 2022

We have significant demand across our 4 product teams. 

Our POs currently manage the PBIs and we ensure we take items onto sprint backlogs based on current velocity from our learning in previous sprints. 

We are however not completing work at a rate to keep up with or match the rate our demand is growing. 

I think there are two considerations here, one our processes/ways of working are they efficient (e.g. currently we have little automated testing)? Probably not an this is something we are looking to address, but this takes capacity which is hard sell given the external demand, even though it would likely have long term benefit. The other is could we expand our teams to increase capacity (knowing that initially this may impact teams efficiency) for a medium to long term gain. 

We are constrained currently by a recruitment freeze, but I am looking to find out what the community would recommend as potential tools to help justify an increase in resource for the team, something tangible rather than anecdotal. Any input would be much appreciated.


10:30 pm November 16, 2022

Our POs currently manage the PBIs

There's your problem. It isn't enough for Product Owners to manage PBIs. They have to manage the Product Backlog itself.

This includes, for example, taking velocity into account when ordering the Product Backlog so value delivery is optimized. The intelligent and considered throttling of demand might well include discussions with the team about reducing velocity, temporarily, so automation can be enabled and longer term value achieved.


11:18 am November 17, 2022

You have specifically asked for

tools to help justify an increase in resource for the team

Can you provide more information around what has led you to increasing resources as a solution?

Depending on your current team sizes, configurations etc. suggestions may actually run counter to your request and include reduction of team size, or use of smaller focused teams or even a scaling framework such as Nexus to help manage dependencies and integrations.

Brooke’s Law: “Adding people to a late software project makes it later”

The team I am currently serving ran into this. Team members were being injected into the team, without the team's input, which actually resulted in us slowing down and delivering less value. Focus was impacted, work fell through the cracks as people thought others had it covered, communications were cumbersome and Events and meetings ran too long. It took some work, but we gained support to streamline the team which has resulted in better focus and more delivery of value. Unfortunately we have many instances in our org of teams adding more people to the problem, only to find things getting worse, and adding more people, and getter worse.

For your 4 Product teams: Is each team focused on its own distinct product? Each with its own Product, Product Owner, Scrum Master and Developers? What are the current team sizes? Is there any sharing of people across Product teams in this scenario? If yes, what are the allocations like and has the cost of context switching and impacts to their focus been considered?

Also what Ian said.


08:57 am November 23, 2022

Thanks Ian and Ryan for your comments.

Currently we have increased capacity from external contractors but this resource is finite. They are likely to leave us at the end of the year and not be replaced. 

Our Teams are between 4-7 people (4-5 without the externals). 

Ryan, your point on focused teams is an interesting one, we work on a platform with many facets, which have been grouped into our Products, some that lend themselves more to a focused product and some that a perhaps a less logical grouping. In an ideal world we would have split the platform into more than 4 products, enabling more focus from the dedicated product team, but looping back to my original point, we are limited by resource. 4xPOs 17xDevs and 1xSM. 

The challenge I have, is how do I deomstrate that getting two more SMs for example would be beneficial or if we split "Product X" into Product "X & Y" and bring in another PO, then we will see tangible outcomes in these areas.

My next step was going to be to run an experiment by doing the above split one product in two and see what the outcome is, but fear this may stretch the team and put more pressure on them.


12:15 pm November 24, 2022

An approach you could consider is illustrating or visualizing the challenges of your current situation.

One SM across 4 teams is a lot of context switching. The impacts of context switching shouldn't be ignored. Some studies show the impact of around 25 minutes per context switch. Even if you reduced this down to 15 mins per, and only considered all of the Scrum Events a SM may support with 4 teams, ~50% of their time could be spent on just Scrum Events (this can vary depending on team maturity), with that alone, 21% of their time could be wasted on context switching alone. This doesn't leave much time for coaching, organizational support, impediment removal support etc. Any additional activity only adds to the context switching waste. A simple spreadsheet can be created to help with calculating cost of context switching and used to illustrate scenarios. This is what I have used in my own organization to help illustrate inefficiencies of shared team members. 

I am wondering about splitting your products. There are other ways to narrow focus. You can have one Product, with one Product Owner and more than one Scrum Team working on it. Imagine you are working towards a Product Goal. Each team would focus on a different concrete step towards that goal each Sprint. Each with their own Sprint Goal focus, but still working on the same Product and making progress towards the same Product Goal. If this goes beyond 3 teams you may want to consider leveraging Nexus. 

Thoughts?


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.