Specialist "adopted" onto a scrum team for a project - not fully utilized but being asked to check with SM/team to be "excused" for other job duties

We faced this problem quite often on our team. We had two types of experts per your definition:

• One who knew the legacy details of the application a little too well who'd be called on to handle old production issues
• Domain expert: like the UX Design expertise you're alluding to.

We had asked all such X-functional folks to track everything on the "board" to understand what percentage of their time was spent where.

At times we saw a 50-50 split and others it was about 70-30 (30 for outside team work).

This helped us inform what their "capacity" is for a sprint. We estimated in ideal days so if a sprint is 2 weeks, you have 10 ideal days and at 50% capacity that's 5 ideal days of your time.

One should always avoid 100% capacity filling owing to unpredictability so we adopted a 75% rule of thumb. Everyone fills up to 75% capacity and keeps the remaining 25% of the items on "top of the spring backlog" (already groomed and ready to be consumed if we finished our 75%). 75% of 5 ideal days is about 4 ideal days of work implying one could do about 2-4 stories (1+3, 2+2, 1+1+1+1, 2+1+1).

The experts also had a "bucket ticket" for out of team work that would remain on the board estimated at 5 points. All work would then become a "task" under that ticket to be tracked/estimated etc., If they didn't get pulled much in a particular sprint, they'd pull in work from the backlog and keep going.

It's possible that they got pulled in "midway" and there was "carryover" so to speak and that's alright. It was factored into the capacity of the next sprint.

Perhaps something like this could be useful where all the information about where your time is being shared and planning against your capacity at a different level from the team's standard 10 ideal days (say).

PS: To anchor an ideal day we made the assumption that 1 ideal day is one where you can get about 5-6 hrs worth of productive time. Everything else is overhead of meetings, breaks etc., This was also done to understand how much overhead was on the team (we found some teams to only have an ideal day of 3 hours! Implying way too much overhead/meetings so we put things in motion to prevent such disruption). This may not be entirely relevant to your question and am adding this purely for clarification/context.

There are two sides of this: the cross-functional team and the expert-specialist. I think we need to define both clearly before we can talk about how they work together.

Cross-functional team: This team has all of the skills needed to deliver a product to completion. In advanced cross-functional teams, they have tuned their skill profile to match the frequency a skill is needed and at what level they need that skill (beginner, professional, industry-leading expert, etc).

Expert-specialist: Maintaining any skill takes time. To maintain a skill at a certain level, there is no time to maintain other skills. Expert-specialists are often the top of their industry. They solve problems other people with that skill cannot. In medicine, this is the specialists to the general practitioner.

Now the first question for your situation is, do you have both of these? Are you filling a gap because the team is not cross-functional. Again, to use the medical analogy, you go to the specialist when you've hit the limits of the general practitioner, but most day-to-day work in that area is done by the GP. If you are acting like a GP for this team when you are a specialist, the problem is not your cross-functionality, but theirs. The best thing you can do for the team is not do the work, but rather help build the skills and resources on the team so they can do most of the UI/UX work most of the time. The hard truth in this case is that the expert is enabling the dysfunctional behavior of the team and needs to put the ownership back on them.

Next, are you an expert-specialist? Do you do industry-leading UX work, write papers, give talks? I've worked with a lot of organizations that say they have them, but I've only worked with 1 that really did. More often, I see people stuffed in a silo. This is a hard reality to face, but it can be a liberating one. If you find this is you, you and your organization have a choice to make. Do you want to be a GP or a specialist? And does your organization value a specialist? I've seem plenty of these trapped people go elsewhere to find a place that actually needs their level of knowledge and skill and be quite happy for it. Or specialists who later founds they loved being the general practitioners of their industry.

OK, let's say you have both. Now how do they work in Scrum. First off, we never optimize a specialist for business. They have special knowledge and skills that other people need. When they are not available, whole teams of people are stopped in their tracks. Always optimize a specialist for availability and maintaining their level of specialization. Next, you don't want to make a lot of rules or manage either of these groups. Keep in mind that you have one Scrum team and the specialists may or may not be using Scrum (I probably wouldn't if it was my choice). Effectively, the specialists are a service-delivery team. I might use Kanban to refine their process and create transparency. At that point, it's about SLA's and negotiation. The Scrum team should be skilled enough in UX to be able to express their needs and the specialist team should refine how they best field the needs and requests of different teams.

How should a scrum master/scrum team handle a situation where they have assimilated a cross-functional "expert" from elsewhere in the company, at a supposed 100% utilisation, when there isn't 100% worth of work and the "expert" keeps receiving external requests, as would be expected in their position?

The best approach I have seen is for the specialist to prioritise the Scrum team's work, but accept other work to fill in any shortfall.

The reason that prioritisation is important is that it allows the team to know their own capacity. If the specialist could pick and choose which bits of the team's work they do and when they do it, then they have effectively become an external dependency.

at each stand-up I have to report back "what I did yesterday" etc (which could be nothing, practically speaking), what I intend to pick up today, etc.

The intention of the daily Scrum is to synchronise the team's efforts for the day. It has nothing to do with reporting. I would suggest you only talk about activities that impact on the team and hence need to be part of that synchronisation.

I probably could, but don't really want to, start to become "cross-functional"

This shouldn't be a problem. Having cross-functional team members with a spread of capabilities often makes a team more productive, but it certainly isn't a mandatory requirement. As long as you and the organisation accept that there may be a little loss in productivity and flexibility as a result, then it should be fine.

The expectation seems to be that we are all at full (give or take) utilization

There is good evidence that having people at full utilization reduces their productivity. The reason is that some amount of slack is necessary to:

• Provide a buffer for unplanned work
• Allow people to grow their skill-set
• Allow for knowledge sharing
• Have time to make improvements

This is one of the areas where, in my opinion, Scrum falls short of addressing real-world problems. Although it's good for teams to pursue the goal of having its members become cross-functional, there are reasons why specialists or experts may be necessary to support the team. These are people who are not on the team on a full-time basis and may support multiple teams across the organization with their knowledge and expertise. Ideally, these specialists and experts are attempting to transfer some of their knowledge and expertise to the members of the team to reduce when they need to be involved or their level of involvement, but this isn't always possible.

When it comes to working with these specialists in a Scrum-like context, I would suggest one of two types of engagements.

The first type of engagement would be an "embedded" engagement. The specialist becomes a member of the Scrum Team. For this to make sense, though, there would need to be sufficient work for an extended period of time for the expert to be nearly fully invested in that one Scrum Team. The work taken on by the specialist could be hands-on, taking on Product Backlog Items and getting them to Done. The work could be teaching the Scrum Team. The specialist may not work on Product Backlog Items individually, but only alongside other members of the Scrum Team as a way to teach them or help them solve the problems.

The second type of engagement would be a "consultant" engagement. The specialist would not be a member of the Scrum Team - they would not attend the Daily Scrum or Sprint Retrospective. They should attend the Sprint Planning to understand the work that they will be supporting and to confirm that it is viable. They may attend the Sprint Review as a stakeholder. When the work for the Sprint comes up, the appropriate member(s) of the Development Team can engage with the specialist to help get the work to Done. This could be anything from helping to decompose and plan the work, conducting the work, or reviewing the "finished" work for correctness before calling it Done.

It sounds like there isn't enough work for the "embedded" type of engagement, so the "consultant" engagement may be more appropriate. As such, I wouldn't expect any particular level of utilization or billable time toward the Scrum Team's project. As a Scrum Master, I would be concerned with ensuring that the team has your support when it's needed in a timely manner. In my experiences, billable work takes precedence over internal or non-billable work. If it was a conflict between two types of billable work (supporting two or more Scrum Teams), there would be a method for resolving that type of concern.

If your primary function is indeed this internal work, rather than the billable work, I don't think that it would be the decision of the Scrum Master or anyone on a Scrum Team to expect you to allocate yourself to work that is outside of your primary duties.

From a broader, organizational context, this may be something to discuss with your front-line manager. Have others in the organization experienced similar problems? How have they solved it? In order to continue adding value to the organization and support the work going on, do you need to become more cross-functional (for example - learning front-end development or testing)? How does the organization see your role and does it align with your career objectives and interests? These would all be useful things to talk about in a 1:1 with your manager.