What to do when Sprint Goal doesn't demand the skills of all team members?

Do you permit those specialists to optimize the product (e.g. address technical debt, refactor for performance, or even maybe add new feature, etc...) in the area of their specialty even if it's not seen as a high priority by the product owner?  

Why is that even a decision for the SM to make?   This is a discussion between the PO and the Development Team on the items to work on in the upcoming sprint.

The existence of "specialists" on a Development Team is an anti-pattern in Scrum, and harms the team ownership and self-management around sprint work and meeting the Sprint Goal.

What if the team thinks that it is the best use of that individual's time, even though the corresponding product backlog item is very low (or perhaps not registered at all)? 

The Development Team can negotiate with the PO around items to work on in the upcoming sprint, but they should remain focused around value delivery, and not resource utilization.   This is another Scrum anti-pattern.

do you suggest adding that work to the sprint backlog even though it has nothing to do with the sprint goal?

In a perfect world, a Sprint Backlog will consist of all items needed to support the Sprint Goal.   Far more common is a Sprint Backlog that contains some items that support the Sprint Goal, and other items deemed important by the PO to deliver in the upcoming sprint.

There is no restriction in Scrum around the number and/or variety of items in the Sprint Backlog, save that the PO must understand and agree to any items worked on by the Development Team, as the PO's primary responsibility is to maximize the value of the product resulting from work of the Development Team.

Thanks for the reply Timothy. I largely agree with you, but have a couple follow-ups

Why is that even a decision for the SM to make?   This is a discussion between the PO and the Development Team on the items to work on in the upcoming sprint.

Fair question. And I think it points out that the better word to use in my original question would have been "discourage" rather than "permit." Does that change your answer at all? I don't think you're advocating the Scrum Master stay out of the conversation, but please correct me if I'm wrong. 

The existence of "specialists" on a Development Team is an anti-pattern in Scrum, and harms the team ownership and self-management around sprint work and meeting the Sprint Goal.

I would agree that "generalizing specialists" are important to the success of a Scrum team, but not always a reality, at least not for the whole team. Would you agree that many immature teams just starting Scrum tend to be composed of specialists? If so, perhaps we should focus around that particular, as I'm interested how that may change your answer if at all. e.g. what steps do you take to coach the team toward more generalization?

Far more common is a Sprint Backlog that contains some items that support the Sprint Goal, and other items deemed important by the PO to deliver in the upcoming sprint.

In that far more common circumstance, is the composition of the sprint backlog upon sprint planning still only associated with items at the top of the product backlog? Or in your experience have you found that it is common for the Dev Team and PO to agree to sprint backlog items that were either not part of the Product Backlog previously, or were in the Product Backlog but below other PBIs that were not accepted into the sprint?

To be succinct, I will respond to your inquiries as #1, #2, and #3:

#1 - I would caution a Development Team against working on anything that doesn't originate from the PO.   

My preference is to place the focus on work identified as most valuable by the PO, regardless of how it fits the technical "specialization" of individual Development Team members.   The PO has identified what is most critical to deliver - it is up to the team to identify how to deliver it, not to propose separate items that correspond to stuff they prefer to work on.

#2 - Certainly I've experienced newer teams being composed of specialists.   It is key for a SM to coach teams about the fragility of such teams in delivering value, and about the inherent benefits of team ownership of work, and broadening skill sets and business knowledge.   

I've supported teams a number of ways to help bring them to a better place.   Work with the team to schedule KT sessions around knowledge gaps.   Coach system flow understanding, and contrast it with existing premature optimization strategies that discount system flow in the interest of "keeping people busy".   Promote strategies like Pair Programming or mobbing to accelerate joint ownership and knowledge-sharing.

#3 - It has not been a common occurrence for me, but it certainly has happened, and it is something that the Scrum framework supports.   In my experience, PO's and Development Teams have selected items from the PB that were not part of the original offer about 1/3 of the time.

As a Scrum Master what do you do when it becomes evident that a sprint goal does not demand much, or even any, time from more specialized individuals on the team?

How evident are the constraints which inhibit the team from meeting a Sprint Goal more efficiently? What bottlenecks, for example, result from the presence of skill silos?

If team members have sufficient transparency over their value stream, they might be able to inspect and adapt in an informed way.

@Timothy, thanks again for your reply. 

#1 - I would caution a Development Team against working on anything that doesn't originate from the PO.   

How do you suggest addressing technical debt? In your opinion, does that exist in the Product Backlog? or Sprint Backlog? both? neither?  

Work with the team to schedule KT sessions around knowledge gaps. 

I'm also curious if you tend to include these as PBIs. or Sprint Backlog items? both? neither?

In my experience, PO's and Development Teams have selected items from the PB that were not part of the original offer about 1/3 of the time.

In your experience are there any patterns around the kind of items that end up making it into the sprint that were not part of the original offer? Also, are the kind of items you're speaking of ever new additions to both the Product Backlog and Sprint Backlog during Sprint Planning, or all they always selected among previously recorded PBIs? 

@Ian, thanks for chiming in as well. Generally speaking, in my experience teams tend to recognize the need for T-shaped "generalizing specialists" through examination around the kind of questions you're asking. They're willing to set up knowledge transfer sessions and pair/swarm for this purpose, but they challenge that this will be an investment of time that will not return dividends within a single sprint. In other words, it requires a compromise in velocity over the short term for the sake of velocity over the long term. And I agree with that personally. And in order to best figure out who should be learning what, it helps for the team to take a long view. If a roadmap across multiple quarters is presented to them to help determine which skills will be in highest demand, they can better assess which skill silos to focus on breaking down and how to do so, e.g. over the course of the next quarter or two (until they start seeing returns on their investment). Do you agree? I'm not clear whether that is consistent with or counter to the Scrum Framework according to the education provided through Scrum.org (e.g. PSM certification trainings), which based on my limited understanding does not advocate planning (much?) beyond a sprint. From my understanding, it is more consistent per the CSM certification training. Please correct me if I'm wrong. I'd appreciate your thoughts on this.

they challenge that this will be an investment of time that will not return dividends within a single sprint

On the other hand, it would seem that prevarication amounts to running up an unmanaged capability debt. The evidence is team members whose skill-sets do not keep pace with the work they need to do.

in order to best figure out who should be learning what, it helps for the team to take a long view. If a roadmap across multiple quarters is presented to them to help determine which skills will be in highest demand, they can better assess which skill silos to focus on breaking down and how to do so

Isn't this being surfaced during Product Backlog refinement?

@Ian, thanks for your reply. I'm not sure I follow your first comment. Are you suggesting that specialists (e.g. a back-end developer with no front end experience) should be able to ramp up in an area (e.g. front end) quick enough in one sprint to make contributions that result in net positive velocity within that sprint?

As for your latter question, this certainly can be surfaced during Product Backlog refinement if the scope of it extends multiple quarters. Do you encourage refining the backlog for more than a couple future sprints? 

How do you suggest addressing technical debt? In your opinion, does that exist in the Product Backlog? or Sprint Backlog? both? neither?

Does the team have a way to manage technical debt that makes it visible and transparent to all interested parties, and measurable from an improvement perspective?   Can the team identify the value component(s) realized through the retirement of technical debt items?

Work with the team to schedule KT sessions around knowledge gaps. 

I'm also curious if you tend to include these as PBIs. or Sprint Backlog items? both? neither?

In my opinion, all PBI's should be customer-facing, and deliver a clear value component.   In your opinion, would KT sessions to improve the team's ability to complete future PBI's, yet do not deliver anything of value to the customer, need to be captured as a PBI?

In your experience are there any patterns around the kind of items that end up making it into the sprint that were not part of the original offer? 

In my experience, the 33% of non-offer based PBI's consist of production support requests, admin tasks, and high-priority items pulled in from the product backlog (either in response to excess team capacity in the sprint, or through identified synergies with current sprint work).

@Tim, thanks for the reply. 

I'm interested to hear from your experience how you and your teams'  have approached technical debt. I'm happy to share the approaches I've seen my teams take. It has been a variety. In some cases, they have been recorded as PBIs, estimated and prioritized. This has worked well for larger efforts, but has felt like a burden for smaller ones. In other situations, teams have attempted to fold technical debt paydowns into somehow-related PBIs providing customer value. I've read many Agile purists recommending this approach. In my experience, I haven't seen it work all too well for reasons I can elaborate on if helpful. In yet another situation, I've seen teams negotiate with the PO a certain amount of capacity each sprint to paying down technical debt. In that scenario, some have elected to still publish it in a separate debt backlog, so to speak, while others felt it was too much overhead to record there and felt it was sufficient to make them identifiable for sake of transparency (albeit only in hindsight) via keywords in descriptions of their git commits. How have your teams tackled this, and to what degree of success? I'm not clear on how this type of work can be effectively originated by the PO, and am interested to hear how effective others' alternative approaches such as yours may have proven for teams.

As for KT sessions, again we've tried a variety of approaches. Some have recorded them in the product backlog and sprint backlog. However, to your point, that does create some confusion around which backlog items (and corresponding story points) are associated with customer value versus not. And for that reason, some have added KT to the debt backlog, and pulled them into the Sprint Backlog (as a reminder to complete it during the sprint even though it won't translate into value on customer facing stories until later after the sprint). Others have elected not to record them on any backlogs, although in this case they tend to fall off the radar and be forgotten. How have you and your teams addressed, and what has worked best?

Thanks for the clarification on the 33% of non-offer based PBIs. That is helpful. Do your teams estimate and prioritize admin tasks and production support in the Product Backlog? Are these scoped/planned for a particular sprint during Sprint Planning, or are they added as unplanned work through the course of the sprint? or both? 

thanks again for your input. Given that Scrum is merely a framework, it's very helpful to hear how others have used it and adapted to be effective in their environment

My philosophy on Technical Debt is that everything that needs to be done to a Product holds 2 values: Negative value if it is not addressed, Positive value when addressed.  This applies equally to new features, enhancements and technical debt. From the Scrum Guide:

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. 

Given that technical debt is something that is needed to be done to a product, why would it not be included as a Product Backlog Item and handled in exactly the same manner as a new feature?  The Development Team members are the best individuals to recognize technical debt and the benefit of addressing it.  The Development Team should work with the Product Owner to introduce the Technical Debt items into the Product Backlog and help the Product Owner understand the values so that it can be appropriate ordered. From there everything is done on equal level and the elimination of technical debt is addressed on a value based basis. 

I think that @Tim's 33% rule plays into my scenario although I never actually thought of it in that way until I read his explanations here.  I might be wrong about that part but I'm still learning new things as well. 

Just to clarify, the 33% isn't so much of a rule, but an empirical assessment of how much "unplanned" work finds its way to the team and their Sprint Backlog (not identified in Sprint Planning).

I agree with Daniel's approach on Tech Debt.   These items should be treated as any other feature-based item.   I also agree with the approach that teams shouldn't just pay off technical debt because it is there.   In my opinion, there are two separate conditions that, if true, should prompt the team to pay off a technical debt item:

1. The technical debt item is causing significant pain to the organization and/or team, either through production issues, customer dissatisfaction, or impeding the efficiency of the Development Team and their ability to deliver value.   In this case, it is wise to eliminate the technical debt as soon as possible
2. The Development Team is working on functionality in the current sprint that contains known technical debt.   In this case, it is convenient to identify these opportunities either in refinement or in Sprint Planning, and "fold" such technical debt into those feature-based items

One key benefit with the #2 approach is to avoid paring down technical debt that is not negatively impacting customers or delivery of value.   There is the likelihood that such features/systems may be replaced altogether at some future point, so lowering the tech debt priority, and simply not paying it off at all, can result in the avoidance of waste (from a lean perspective).

I would not advocate the existence of any backlog (tech debt or otherwise) apart from the main product backlog.   Such an artifact reduces transparency and adds unnecessary complexity.

In my experience, my teams have created non-pointed items in their sprint boards if they need to be reminded of certain tasks that do not have customer-facing value.   Visibility of work is key, in my opinion.

Thanks for the replies guys. @Daniel, I like your perspective of negative value and positive value, as well as your justification per the Scrum guide why technical debt should be in the product backlog. @Timothy, I like the two conditions you suggested for prompting tech debt payoff. Also, thanks for the clarification about non-pointed items in sprint boards. Is sprint board in this context synonymous with Sprint Backlog? And, referring back to your initial reply, does that contain the "other items deemed important by the PO to deliver in the upcoming sprint"?

I should rephrase my last question there to better clarify what I intended : are those non-pointed items in the sprint board the "other items deemed important by the PO to deliver in the upcoming sprint"?

Are you suggesting that specialists (e.g. a back-end developer with no front end experience) should be able to ramp up in an area (e.g. front end) quick enough in one sprint to make contributions that result in net positive velocity within that sprint?

I don’t think it’s likely, yet nor is the timescale for ramping up likely to constitute a good reason for delay.

As for your latter question, this certainly can be surfaced during Product Backlog refinement if the scope of it extends multiple quarters. Do you encourage refining the backlog for more than a couple future sprints?

In your team’s case, how much refinement ought to occur in advance so there is time for them to deal with any difficulties, and upcoming Sprint Planning sessions are not put at risk?

How big is a Product Owner's role in team composition, in regards to budget?  Wouldn't it be fair for the PO to have input on potentially redundant numbers of developers?

@Ian, thanks for your reply. I agree that it is no good reason for delay.

In your team’s case, how much refinement ought to occur in advance so there is time for them to deal with any difficulties, and upcoming Sprint Planning sessions are not put at risk?

I'm not sure I follow your question exactly, since my answer seems like it may be circular, but I think it'd be multiple quarters. That is, it seems that it takes at least a quarter before cross-training a team member enables them to be productive in a new functional area without being a drain on the other educating/supporting/pairing team member(s). So if the team has an understanding of their stakeholders' wishes across multiple quarters, they can start cross-training based on the skillsets that they forecast to be most in demand and better position themselves to deliver on those wishes. Is that reasonable in your opinion?

@Alex, thanks for chiming in.

How big is a Product Owner's role in team composition, in regards to budget?

Actually I'm glad you asked that. Is there any standard in Scrum regarding who is responsible for team recruitment and assembly? At my company it's often the PO or some senior manager / director (for better or worse).

Wouldn't it be fair for the PO to have input on potentially redundant numbers of developers?

I'm not sure I understand that question. Are you suggesting the PO ought to be able to offer an opinion on which skillsets should be represented by more than one person on the team?

I'm not sure what I'm suggesting, actually.

Imagine team size had no relation coordination issues.  Imagine a Development Team was 100 people.  You could say they can work on 10 times the amount a team of 10 people could.  But it might not be valuable to the Product Owner to work on such a huge amount.  So is it fair for the PO to influence the number of developers?

@Alex, Personally I think it's fair for the PO to influence the number of developers. I think a conversation between the PO and the team around the business needs and the definition of done would guide the Scrum team at large to an appropriate number

@Ian and any others with opinions on this subject - I'm still very interested in hearing feedback on the following (copied from my May 9th comment above):

it seems that it takes at least a quarter before cross-training a team member enables them to be productive in a new functional area without being a drain on the other educating/supporting/pairing team member(s). So if the team has an understanding of their stakeholders' wishes across multiple quarters, they can start cross-training based on the skillsets that they forecast to be most in demand and better position themselves to deliver on those wishes. Is that reasonable in your opinion?

thanks in advance.

It is reasonable to expect Development Team members to improve their degree of cross skilling, while it is unreasonable to expect this to happen quickly. It may take several months. Product Backlog refinement can therefore be instrumental in forecasting the competencies which are likely to be required for upcoming work. If this is borne in mind, your suggestion seems reasonable in my opinion.

I agree that it is reasonable to expect Development Team members to improve their cross skills.  But you have to also take into account that every person has different career aspirations and their career is theirs to control. If they do not want to learn cross skills, there is nothing you can do to force them to do so. An organization can make a decision on whether to maintain a relationship (i.e. keep them employed) if the individual does not choose to meet the needs of the organization.

On the expectation of how long it takes, that depends entirely on the individual learning, the individual teaching, and the technology involved.  But in my experience it has not been a quick process very often. It usually takes weeks for the "new" individual to get to a level where everyone is comfortable with their working independent, especially if this is a critical component.

Refinement is a necessary activity to help with this as it aids in knowledge transfer and to identify opportunities suited for the cross training.  Also, I highly recommend pair programming as a tool for this.  But make sure it is done correctly where there is a driver and navigator rotating roles frequently.