Scrum Masters (SM) & Product Owners (PO) to Scrum Teams
SMs and POs are key to the success of scrum teams that are able to achieve and sustain high performance. Anyone that has worked with a good PO/SM know that these resources are incredibly valuable and life without either of these roles would make for very difficult times. On the flip side, those that haven’t had the opportunity to work with good SMs or POs would argue that these resource investments aren’t needed. In a world with two vastly different outlooks it’s important to understand why leaders can feel this way. In my experience, when SMs or POs aren’t valued, it hasn’t been due to a lack of role experience, the wrong personality fit, or a lack of training. The number one contributor, again in my experience, to SM/PO failure within an organization has been overallocation which leads to lack of value added to stakeholders.
If I asked you to pause and take note of your current ratio of SMs to scrum teams what would it be? Would it be 1 SM to two 2 teams? Would it be closer to 1 SM to 4 teams? Would it be even more than that? Now, do the same thought exercise and apply it to your PO role and note it down. If you answered 1 resource to 3 or more scrum teams on average across your organization, you probably aren't maximizing the value of your resources and may be experiencing issues. These roles are hands on, detail oriented, and highly time consuming roles so the right ratio is key to their success. Here is an example of what happens when a PO is over allocated:
How many teams can a SM/PO handle effectively? Well, like most things, it depends. First, all scrum teams are not created equal. In the example above I mentioned 3, but there are a number of factors to consider when driving towards the right ratio. Different teams have different complexities associated with them. In order to apply the right ratio for a given SM/PO resource you must fully understand the capabilities and experience of your SM/PO AND the complexity of the scrum teams they are likely to support. I like to apply maximum caps and work backwards based off factors that I believe make up the complexity of the scrum teams that they serve:
Complexity components:
Size - Assess the size of the scrum team to determine the complexity level. In most cases the more cooks in the kitchen, the more complex the team.
Interdependency - Is your team self-contained or are they highly interactive with other scrum teams across the organization? Team complexity is going to increase as teams dependencies increase.
Type of work - Think about the technology your teams are delivering. Is it new to market type work that has never been delivered before or is it something that is easily repeatable that has been in the market for a while? If the former, make sure you have the right skillsets and experience supporting these teams because these can be highly complex teams.
Coaching: Does your team require a lot of coaching? Are they resistant to change and coaching? Maybe they are stuck in their ways and aren't comfortable trying new things or being a team player? Scrum team complexity will go up when teams resist basic process coaching and it can take skilled resources to navigate these waters in order to gain the trust of the team.
Each team should be assessed on each of the components above to determine if the team is limited, moderate, or highly complex. Once you have determined the complexity of the scrum team you can assign points that you see to the right of the graphic below. If a scrum team complexity components fall in different buckets I will typically ask the team to round up to the more complex rating. Read through the following to understand the differences in complexity from group to group:
Once you have worked to identify the scrum team complexity and you have values assigned to each of your teams, you can start to map your scrum teams to your resources. Keep in mind that as a manager you will want to align resources to their strengths and interests in order to maximize productivity and moral. Those specific nuances are not part of this discussion but keep it in the back of your mind when allocating resources to teams as it is very important. Here are a few additional rules to keep in mind:
Allocation Rules:
Max ratio: 1:3
Max points (See graph and points visual): 3
Team ratio vs point totals: Cap your resource at which ever hits 3 first but remember that 3 is the absolute max and most resources will thrive between 2-2.5, even less when they are junior level.
Resource experience: Resource experience plays a key role in ones ability to be an effective SM/PO but this can only be assessed by their manager with feedback from the resource themself.
Recommended points based off job level (Basic 1-4 scale):
Level 1: .5 - 1.5 points (Junior role)
Level 2: 1.5 - 2 points
Level 3: 2 - 3 points
Level 4: 2.5 - 3 points
** Keep in mind that this is a guide and that this leaves little capacity for any special projects or responsibilities that resources may also be asked to deliver. If your resources do have special projects or responsibilities, you should consider reducing the points allocated to them to allow for time spent elsewhere.
Using a guide like above will help to maximize your resources ability to add value to the teams that they support. When resources are stretched too thin they are likely to do little very well. In the world of a SM or PO It is very important that they are adding value to the team and that they are collaborative, representative, authorized, committed, and knowledgable. They must be servant leaders to the teams they support fully available at all times. If you find that resources on your team are not adding the value you intended, check to see if they have been over allocated and if they have been, start to make adjustments.
Thanks for the read!
Author – ‘Process Pat’ McClain
Experience – I am a process coach that has been hired to lead large scale global process change initiatives that drive competitive advantages in different areas such as increased predictability, improved productivity, cost reduction, and increased efficiency across Product Development and other related organizations. These results are achieved through efforts I have led related to agile maturity, capex reporting process changes, and toolset analysis/consolidation efforts that align with the people and processes of the organization I am working with.
Disclaimer: This article is not affiliated with current employer and is based off prior professional experience over the last decade.
Comments