After a re-org we ended up with one larger team of specialists:

  • designers
  • user experience engineers
  • 3D artists (we are in gaming)
  • developers

Great, cross-functional team! BUT they are all specialists. And they need to collectively decide what the team can fit in a sprint.

I considered thinking of them as 4 smaller teams with their own estimations and historical velocity. But that sounds lousy.

What alternatives do I have?

  • How big is this team? How many people have each specialty? Are there any dependencies between the work that each specialty takes on?
    – Thomas Owens
    Commented Oct 1, 2021 at 11:57
  • 4
    I'm confused; isn't the point that they discuss amongst themselves and come up with a commitment that they can deliver? Are specialists unable to discuss or agree with specialists in other disciplines? If they can't work together, then they're not a cross-functional team.
    – MCW
    Commented Oct 1, 2021 at 12:38
  • I believe we have a mentality shift to work on. Before, these guys would be working in specialist silos and they could easily assess everything in their backlogs. The backlogs were geared towards that, and every team member was able to understand and pick up anything on those backlogs. Now that they are such a "heterogeneous" group, they are struggling to commit to work as a whole
    – Philip
    Commented Oct 4, 2021 at 11:45

3 Answers 3



(I was so tempted to end my answer at just that one word.)

Seriously, though - your problem is that you don't have a single, cross-functional Team. You have four teams that call themselves/are called one team.

Your developers (and they are all called 'developers' in Scrum parlance) don't need to be generalists, but the goal is still for them to become T-shaped. The only way for them to do this is by associating with each other, talking about each others' specialties, learning, and assisting one another.

As long as your 'designer' developers look at a 3D art task and think 'that has nothing to do with me', this problem is going to persist.

What you need to do is change 'that has nothing to do with me' to 'that has something to do with my Team. I wonder how I can help?'.

The first step on that is getting your Team to consider itself a single coherent unit, rather than 4 connected sub-teams.

Get them talking to each other.

Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

  • Thanks for the input Sarov. Those are the individual contributors' competencies. These guys are not all developers and they will not become t-shaped across these skill-sets. Artists will not code. Coders will not create 3D models. UIUX dito.
    – Philip
    Commented Oct 1, 2021 at 15:43
  • @Philip To which I ask... why not? I'm not saying artists need to start submitting pull requests for the code. But why not have them learn how to read the code, at least, for example?
    – Sarov
    Commented Oct 1, 2021 at 15:45
  • Simple, because they would rather quit and cross-train. I have asked that question, and for most part people wanted to work on items that are their speciality
    – Philip
    Commented Oct 4, 2021 at 11:50
  • Fair, though that then puts the onus on them to figure this out, which brings us back to my point of 'Talk'. What I would do at this point is lay out the problem, lay out my solution, lay out the issue with my solution, and then ask them: "So, what do you guys think? Can anyone come up with a better solution than mine to get collective ownership going? Or do we have to go with mine?"
    – Sarov
    Commented Oct 4, 2021 at 13:35
  • 2
    To Sarov's point, these are not independent tasks. The way you will integrate a 3D model into the code is part of how you build the model. How I write code for the same feature is different for one UX design or another. Very few features should ever involve fewer than two disciplines and the fastest way to the goal there is for those disciplines to work together. Working separately and then integrating is almost always the slower route.
    – Daniel
    Commented Oct 4, 2021 at 14:32

Think deeply about when and where the team members need to collaborate and build your approach based on that.

If the individual disciplines are on separate work streams and rarely need to coordinate then your solution is likely to be less like a traditional Scrum team. Possibly a Kanban framework would be more appropriate and knowledge sharing where it may be useful.

If the individual disciplines contribute to a single work stream and have dependencies on each other then traditional Scrum makes a lot more sense.

In this situation you may want to consider a two-stage estimating process. The first stage is to estimate as a team, taking in to consideration the difficulty/ease for each discipline in completing the work. The second stage is a sanity check, where individual disciplines check to ensure they are not overloaded or under-loaded in the coming sprint.

For example:

The team has a capacity of 20 story points and they jointly estimated items on their product backlog until they reached close to 20 points to put in the next sprint. We then broke the stories down into discipline specific sub-tasks and checked that there was a good balance of work given the makeup of the team. We realised that the 3D artists were going to be overloaded, so took out one particular story and replaced it with something that had less 3D involved. We also noticed that there wasn't much to do for the UX engineers, so decided to bring in a task to look at the UX on a couple of planned stories that are still in the backlog.


Just to add one component to the mix:

Try something, then fix it when it doesn't work.

This depends pretty heavily on Sarov's answer (if the team doesn't talk, they can't fix stuff), but this is another important component of making Scrum work. For any Scrum team, its first few Sprints are likely to go askew in some way - too much work, not enough work, too much work that requires a narrow specialty, etc. The important thing is that the team gets together in the Retrospective and looks at ways to smooth out those issues.

Keep in mind:

  • A Retrospective is not a session to assign blame. The team should take joint responsibility for the Sprint and consider ways to improve for the next Sprint together.

  • It could help to focus on the end goal - to produce a potentially-shippable Product Increment. Spend some time looking at what it takes for the team to deliver a Done Increment, and break that down to see how each specialty fits into that.

  • Consider ways to vertically slice the work thinner - what is the absolute bare minimum of a feature the team could deliver in a Sprint, and how does everyone contribute to that? If a single feature (e.g. a character model that can walk around) requires everyone's input to deliver, then it should be easier for the team to estimate its size as a whole relative to other features.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.