Conflict between priorities and skillsets in the backlog

Question

So we have a very diligent PO who does a good job of prioritising the User Stories in the backlog when it comes to planning. Much of the work is highly specialised though, and - as well as being Scrum Master - I'm a generalist developer and my team has some quite greenhorn juniors. Hence, what happens at planning is that our sprint gets filled to capacity, but then there are people (often me!) left with low allocation because there aren't really that many stories appropriate to their skillsets and levels.

My instinct (especially in this time of remote working when communications are harder and motivation is not always guaranteed) is when the sprint is full, to skip stories in the backlog to find them things they can do. This has annoyed the PO as he wants things done in priority order.

So there's conflict here - stories ordered solely by business goals might not get done, or might get poorly done if allocated to the wrong person. Even skilled devs working in a relatively new area will make mistakes. And switching people in and out of epics seems like a bad idea in some ways. My pragmatic solution - keep priority order till the sprint is full, then skip, hasn't been accepted by the PO and I am left a bit confused as to how to move forward.

Answer 1

The Scrum Guide does not talk about prioritizing the Product Backlog. Instead, it talks about ordering the Product Backlog. Priority is only one factor that can be used to determine the ordering of the Product Backlog. Dependencies between work items is another factor, but the Product Owner can choose any factors that are appropriate to help maximize the delivery of value.

The Scrum Guide also talks about cross-functional Development Teams that take accountability for the delivery of a product or service without recognizing titles or sub-teams. Although it seems like the team, as a whole is cross-functional, it seems like there may be sub-teams (perhaps of size 1) within the team. It's natural for individuals to have specialized skills or preferences as to what work to do, the emphasis needs to be on maximizing value delivery.

This is where the Development Team and Product Owner need to come to some level of understanding and agreement on how to proceed. One option is to do what the Development Team is doing now - everyone focuses on their particular strength if they have the capacity, even if the work they take is not the next most important. The other option is to work on developing the skills of the Development Team members so that everyone is more capable of taking on any piece of work.

There is a risk of having someone with less experience in a particular domain working in that domain. However, that risk can be mitigated through various teaching and mentoring options. Eventually, though, the skills of everyone on the team can be leveled up.

Fundamentally, that is the choice. Either Development Team visible output can take a short-term decrease as the team builds their skills in other areas or the output can be maximized yet this may not maximize value.

Personally, I would tend to favor the short-term decrease and build the skills of the whole team. This reduces dependency on individuals and the overall risk of the product. Not only would it achieve the results that the Product Owner wants to see, but it would also make sure that there are no single points of failure in the team with respect to skills and knowledge.

Answer 2

I cannot answer this from a scrum standpoint; however, in other priority schema, the ability to perform is part of the criteria. To say it another way, both risk and cost are criteria and the labor and materials to do a task contribute to both of those two things. If you don't have either the numbers or the skills, both risk and cost climb and that would effectively reduce the priority of the action. So it appears your PO is prioritizing using incomplete criteria.

Answer 3

This is a reasonable concern from the Product Owner. While another answer was correct that the Scrum Guide says it is ordered, it also discusses how the PO orders it:

• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;

However, while there may be tension between the PO and development team, we do not want the relationship to be antagonistic. When working with teams, I usually ask them to first assume everyone is doing their best. It isn't often productive to assume people are being deliberately deceptive or difficult. Now, we must first acknowledge the reality:

We have a Product Backlog prioritized to do work in the best order possible from a problem solving and value-delivery standpoint and we can't deliver on that as a team.

This is not a condemnation of anyone. It is a simple fact. Further, it is true of every team to some degree. Even the best Scrum team ever will sometimes not be able to solve problems in the best order - it happens.

Now, there are two questions to be asked here:

1) what is the most valuable work to do or problems to solve with the team that we have today?

2) how can the team improve how it works or its own skills to be able to field the work more effectively?

From your description, it sounds like the Product Owner is not engaging in question 1. It is hard to tell from your description of the situation if the Scrum team is engaging with question 2. Your proposed approach may be just fine as a bridging strategy. However, my concern with it is that it allows both the PO and development team to avoid both of these hard questions.

Answer 4

Your description of the conflict displayed perhaps two root causes:

1. a need for management to take action about the team capacity
2. the lack of one key element in conflict resolution: listening to the other part.

---

Here is why:

there aren't really that many stories appropriate to their skillsets and levels.

Is this statement unanimously agreed upon by the team? This could be a management issue - training, reallocating team members, hiring, retention, etc. Otherwise, maybe the stories have to be broken into smaller parts.

My instinct [...] is to skip stories in the backlog to find them things they can do. This has annoyed the PO as he wants things done in priority order.

Could this be instinct of staying in the comfort zone? Sometimes we are afraid to take it slow to learn new skills, for we, our peers and/or our organization seem to recognize speed or number of accomplished tasks over customer impact. The product owner (PO) should be one of the advocates of the customer needs, who may be, in many cases, the current or future sponsor of the development team.

Doing what you can vs. what you should do

Could you be mostly concerned about capacity and undervaluing the business goals? Have you considered addressing them with the PO? Perhaps, instead of only suggesting skipping some user stories, you could also propose (with some general agreement from the team and management) a plan to address the skillset of the team – so you can then give a fair time when those high priority stories can be done. That should delight the PO!

The improved communication may require:

1. listening to the PO to understand the customer needs
2. asking questions and even challenging statements, for sometimes what the customer asks for may be different from what he/she really needs and there may be other less effortful and creative ways to accomplish that particular need
3. motivating the team to learn and get out of comfort zone: positive impact on the customer, technological challenges, career growth, hireability, etc.

Answer 5

It's also worth teaching the developers about "the five-minute rule":

If you find yourself stuck on something, or looking for information and you can't find it, for more than five minutes, ask someone to help you.

Every developer starts their career in the same place, and everyone on the team is part of a team. Many a line of bad source-code has been written by someone who was simply unaware and/or afraid to ask. That's demoralizing to the person who did it, and the entire team pays the price ... unnecessarily.