Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
After a re-org we ended up with one larger team of specialists:
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?
(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.
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:
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.
