User stories, small team, unbalanced work

A Sprint should be include any work needed to accomplish the Sprint Goal.  It isn't about whether the people have enough work to keep them busy for 8 hours a day.  Stories are a commonly used method for describing the work that is needed but they are not specified at all in the Scrum Guide.  However since you use them, here are a few suggestions from similar situations I have encountered.

Not everyone will be fully "utilized" during a Sprint.  In fact, I'd be really cautious if that is the case because you are not leaving any capacity for adapting to new situations that can arise.  Plan your Sprints to accomplish a Sprint Goal.  Then have some extra items "ready" at the top of your Product Backlog that can be pulled in should the team find themselves with extra capacity.  Another way to use extra capacity is to identify other opportunities for work such as addressing technical debt.  

Another option is to find creative ways that your Artists can help the Development Team. I'm going to make an assumption that you are working with some type of entertainment such as a game.  I have worked with game companies in the past and that is the only industry that I know of that uses Developers and Artists.  So, if that assumption is correct, could the Artists spend time looking at the implementation of the art within the code branch that is being implemented?  That would allow them to partner with developers on increasing the visual effects of the art without having to wait for the "testing team" or what ever you have in place to validate.  This cuts down time and effort on delivering results to the end users.

Those are a couple of ways for you to refocus your thinking.  There are others but I'm going to save some for the other commenters. 

I do want to call out a few of your statements that raise concerns. 

 I was told the backlog shouldn't have hundreds of stories in it.

Not sure who told you that but I don't necessarily agree.  Yes, a small backlog is easier to manage but according to the Scrum Guide

The Product Backlog is an ordered list of everything that is known to be needed in the product. 

If there are hundreds of things to do then to the product then it could be a long list of items.  This makes management more difficult but there is nothing that says it can't be done. 

...so I am still left with several stories...

I worry it's going to leave me with unbalanced sprints or artists sat twiddling their thumbs. 

 Should I be splitting those stories even further down?

Or have I done/not done something else that I should have?

Why would any of these be your concern? They should all be the concern of the Scrum Team with no single person responsible.  The Scrum Team defines the work that needs to be done and the Development Team identifies how they will work.  The Scrum Guide has this to say about the Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. 

 

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

 

Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

For your team, the Artists are part of the Development Team.  So ask the Development Team how they feel they should work and how the Product Backlog Items can be defined/managed in a way to make them successful. Your questions are stated in a way that indicates a possible problem and not an actual one.  Why not wait for a real problem to arise, inspect it, adapt accordingly as true empiricism guides?

Regardless of how finely Product Backlog items are refined, would team members collaborate with each other to meet an agreed Sprint Goal? How do you see teamwork being demonstrated?

Good questions!  One of the trickiest things about being a Scrum Master is getting comfortable with the fact that you aren’t responsible for how the team is organized, the team is. 

So rather than thinking of these issues as your responsibility, I’d think of them as an opportunity to coach & mentor your folks in becoming a truly self-organizing team.

I would start by chatting with the designer to see how they’re feeling about their work.  If a team hasn’t gelled, it can be hard for designers to feel comfortable speaking up, so some one on one mentoring might be useful.

Then I would either bring up the issue of the balance of coding vs art with the team as a whole, or I’d let the designer do so if they’re concerned about it.  

Good luck!

 

Also, it’s not necessarily a problem that an artist/designer has less work to do on an individual Sprint.  

One complaint I’ve heard from designers about Scrum is that it can be hard to break up some of their work so it fits in Sprints that work for developers.  For example, great UX work for a complex UX problem can take a month or two of coming up with many,many iterations of coming up with design ideas and testing them on users.  You certainly can fit it in Scrum, but — at least according to the designers I’ve worked with and talked to — it’s often not an easy fit.

So if your designer has some down time in some Sprints, maybe that’s an opportunity for them to do UX prep for an upcoming Sprint where the UX is tricky and getting it right is critical.  Or maybe it’s an opportunity for them to do some guerrilla usability testing on work from a previous Sprint that was “done” but isn’t as good as it could be.  one more reason to chat with the team’s designer.

Many thanks for all the very helpful feedback, suggestions and information! It's really helped and also given me so food for thought and I really appreciate it!

Daniel - you guessed it! Working in a games studio :-)