How to write a user story involving artistic work?

Question

Using Scrum, what would be the way to define, structure and estimate a user story, containing work for an artist?

The main problem that I'm interested here is that an artistic story can take a long time to finish, due to the nature of the work.

For example, let's say I work in cross-functional team of 8-9 people on a highly visual 3D app (think video game). I could write a user story like this one: "As a user, I want a car to move through the map"

This story would involve the following tasks:

• Make an approved concept art of the car
• Make an approved 3D model of the car
• Integrate the car model in the app
• Program the controls of the car

Other than the fact that the user story in itself is a little big, the problem is that the 2 first tasks are subjective, so the artist can take a long time doing iterations. For example, he could create a concept art in a day, show it to the creative director, being asked to change some things, redo another concept, change it again because he's not satisfied and then show it again to the creative director. Only then the concept is approved. Now the second task can start.

Even if we break the user story in smaller parts, the time to complete it can still be greater than the sprint, or the effort estimation could be way off. Also, breaking this story in smaller parts is making an "horizontal slice" of the app and not a "vertical one" as would be better.

What do you suggest in this situation?

Answer 1

As you pointed out, part of the challenge with this sort of user story is that it's big and takes a while to complete. Let's say the actual user story is something like this:

As a player who's got a basic grasp of the controls, I want to race against sinister opponents so that I have a reason to improve my mastery over the game.

I know this breaks a little from yours because it's an AI, not player controlled, but the idea is the same. Now, to break this down, I want to ask two questions:

1. What delivers the biggest value to the user in the shortest time (in traditional project management this was called weighted shortest job first, or WSJF)
2. What are the riskiest unknowns in delivering this to the user?

Let's look at two possible paths. The first is that I decide I need a fun opponent. In this case I'm going to ignore the model for now - probably just a color-swapped version of my player's car. This broken down story will probably read very similarly:

As a player who's got a basic grasp of the controls, I want a challenging opponent so I have some marker to test myself against.

I'll probably focus on getting a simple UI together and then get people playing with it. This will almost certainly not be all of my players, but a small group that has been put together to get feedback. From here I'll decide what is next: better AI, catchup mechanics, aggressive driving, or maybe it's time for the car to get a new model to look cooler.

OK, let's look from another direction. Maybe the most important thing is to have that car look genuinely sinister. While it's pretty rare that the aesthetics are more important than the gameplay, it happens from time-to-time, especially if you're reusing an existing mechanic. (Holiday Skins for example) Now my first backlog item will focus on confirming my design. You may notice I didn't say User Story. Not everything in the backlog has to be a User Story. Here, my biggest concern is making sure I've got a design that will really land with the players, so that concept art is key. That's probably my first thing and I will almost certainly show it to real players and see the reactions. If it doesn't land, I haven't spent a lot of time modeling and integrating it. I've even seen games companies create a few ideas and put it to a vote with the fans.

It is important to note that backlog items should be close-ended. The concept art could absolutely get more feedback that results in more work. Open-ended tasks assume that the work is worth it no matter how much it costs. I've never seen a task where this is true. Instead, we make it close-ended. Something like "Create 6 different concept art pieces and put them into the online poll". You might get some feedback that leads you to create another 3 - that's a new backlog item. Now you're paying attention to how much time and money you are spending on this work and can avoid overruns.

Now, let's say I'm doing a model for a movie and it just takes a long time - this thing has to look really good. Creating low-res versions will let us drop it in rough cuts, then you can choose if there are areas that are important to focus on first - or you can group up on work, with different modelers working on different parts of the model.

I've heard this idea many times that artistic work doesn't fit in sprints, and I'm not an artist myself, but I've worked with dozens of artists that work iteratively and every art class I've taken in my life taught me to work iteratively. I've worked with a few game companies myself and know of quite a few others that work with Scrum. In fact, I spoke to someone at a game company recently whose team worked in 2-day sprints (which is way more extreme than I would do, but hey, it sort of ends any debates on if a 2-week sprint is possible).

Answer 2

There are two aspects of this question, and depending on the perspective, the answer may vary.

Agile promotes the usage of the Minimum Viable Product. In the case of the video game, you wouldn't be too concerned about having the best shaped car of all times from iteration one. The goal is to have a conceptual functional car that does basic operations.

From the other perspective, there may be cases where the car itself is expected (for any reason) to be optimally delivered (i.e. we're assuming that delivering a single car would add business value, which is something very unusual unless the game itself is already in production). Being that the case, the car in itself would be a story too big to fit into a single iteration... and per definition, would become an Epic.

Bottomline: You can decide the best approach by assessing how you can deliver value faster and better.

Answer 3

Maybe it's just me, but I consider the whole concept of software development to be a creative/artistic endeavor. And thinking about it, I'm not seeing why anything would have to change when you go from a story that says "make a functional widget" to one that reads "make a pretty widget".

Try applying the same measures you use when developing the code, I think you'll get quite far.

Other than the fact that the user story in itself is a little big, the problem is that the 2 first tasks are subjective, so the artist can take a long time doing iterations.

If I'm asked to design a new form to encourage people to sign up for something and leave as much information as possible, that's also subjective, and I can also spend a lot of time doing iterations.

For example, he could create a concept art in a day, show it to the creative director, being asked to change some things, redo another concept, change it again because he's not satisfied and then show it again to the creative director.

Same here; the creative director is a stakeholder in the process. If I'm building a form, I'll show early sketches of it to my stakeholders, see if I'm getting it right, and iterate rapidly on that.

The biggest difference between code work and artist work is that we've got a lot of experience applying the rapid iteration process to our code work, and many artists don't have that experience yet. But the parallels I'm seeing are pretty big, and I think the same rules will apply.

So basically:

• make sure you understand the needs of the story
• focus on the minimum viable
• iterate rapidly
• show new versions to key stakeholders as often as you can
• collect feedback early and often
• measure, collect data
• stop when it's good enough for now and something else is more important

Whenever you (or your artist) are stuck, look to parallels in other fields and apply the same methods. Scrum isn't explicitly designed to handle software projects, and even if it is, artistic expression and subjectivity are key parts of pretty much all software. Use the tools you've seen for other types of tasks for these as well.

Answer 4

TL;DR

By treating artistic work as somehow different from other types of development work, you create a waterfall-like project pattern that suffers from BUFD (Big, Up-Front Design). This often generates scope creep, and typically reduces collaboration by exempting the creative work from standard agile practices.

The solution is often to reframe your expectations for the creative work, and to leverage the iterative development patterns to manage scope through validated learning and time boxing. This is not trivial, as it represents a significant paradigm shift for many organizations, but it’s essential to avoid the trap of “design siloes” or “artistic ghettos” that can derail the rest of the project plan when improperly decoupled.

Artistic/Creative Work Should be Iterative & Incremental

Part of the challenge here is how you’re conceiving of the work. You’re putting “artistic” work into a different conceptual bucket than other types of work, and so are losing out on the collaborative and iterative aspects of development.

While artistic endeavors are certainly more subjective than other types of work, your goals for such work should still include:

1. Making art/design part of a thin, vertical slice of functionality instead of a standalone deliverable.
2. Thinking in collaborative terms, rather than as a ping-ping between a single task-performer and a task-approver.
3. Following INVEST criteria as closely as possible, especially by taking a test-first approach to UI and graphics design.
4. Ensuring the work is iterative by respecting Sprint boundaries, limiting scope, and treating adjustments, changes, and rework as new work to be scheduled for a future Sprint.

Some people find it hard to think of creative endeavors as testable. While it can be hard to design executable tests for non-software or non-UI visual elements, it’s not impossible. Pragmatically, what you’re really after is getting the team and the stakeholders to think about the acceptance criteria first, and for everyone to treat work that meets the Definition of Done as complete for the current iteration. This is a scoping challenge, not a creative one! Anything that isn’t part of the agreed-upon Definition of Done, or that represents a change that expands the level of effort beyond the current estimate, should be treated as future work.

Scoped, Iterative Examples

It’s important to think of creative work as iterative. “Make an approved concept drawing of a car” isn’t an iterative task, but the following could be elements of a larger theme or epic:

• As a body panel machinist, I want a concept drawing that I can evaluate for production line feasibility.

• As a procurement officer, I want a concept drawing that I can evaluate for initial estimates of how much steel I need to order.

• As a marketing specialist, I want a concept drawing I can show to our sales channels to gauge market demand for the new design.

These types of user stories provide context which can help scope the artistic work. In addition, they give you a framework for developing a Definition of Done and testable criteria for the drawings, such as having estimatable dimensions, a clearly- defined scale, or callouts for any design elements that might require precision machining or special production processes.

Furthermore, by making the stories about validated learning (e.g. as an opportunity to review and evaluate a design, rather than a piece of work to be “approved”), you create opportunities to collaborate and refine the artistic concepts over time. If stakeholders don’t like the design, or want to make changes, that doesn’t invalidate the work that was done. Instead, it simply creates new scope for future iterations.

This type of creative work is thus built up in an incremental, iterative fashion that can be more easily estimated and more easily delivered in bite-sized chunks. By getting away from the notion of “big, upfront design” and by moving to an iterative model with just-in-time design, you allow the creative work to leverage the same agile practices that other types of development work benefit from.