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?


4 Answers 4


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).

  • The point that not every backlog item needs to be a user story is really interesting! If I understand correctly, a user story is better, but if the artistic work is too big, a work item can be created in the backlog, specifying each approval step. So the approval is not contained in the backlog item anymore. It's still an "horizontal" slicing, and the effort is still hard to estimate on the complete "epic", but I guess we dont have the choice if we want to iterate on an artistic work...
    – David
    Jan 30, 2019 at 2:03
  • 1
    I don't know if I would even say that a user story is better (though I really like them). The point of a user story is to help the team empathize with the user's needs and focus on fulfilling them. There are other techniques like spikes that are designed to reduce risk and validate learning. A lot of agile teams actually lose most of their approvals because many approvals are replaced with user feedback. To put it in an advertising context, most designs are either signed off by a marketing director or shown to a client for feedback - rarely both.
    – Daniel
    Jan 30, 2019 at 2:14

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.

  • 1
    Good point about MVP. There's a really good video about MVP in video games here: youtube.com/watch?v=UvCri1tqIxQ
    – Daniel
    Jan 29, 2019 at 21:15
  • You seem to confirm that with long artistic work, I have no choice but to break it into multiple items and join them in an epic. But you bring an interesting point about the "production" phase. Would you say that things are different in this phase?
    – David
    Jan 30, 2019 at 1:41
  • Yes - when you have something already adding business value, it's easier to add further small increments that could add further value from scratch. However, if you're building something entirely new (i.e. not in production yet) you need to buy a MVP before you can deliver any meaningful business value. Hope this makes sense, happy to chat over a chat room if necessary.
    – Tiago Cardoso
    Jan 30, 2019 at 9:27
  • The MVP is a specific pattern from Eric Reis Lean Startup and is only applicable to finding product-market fit as quick as possible. No software house is release a AAA title as an MVP. MVP remains one of the misunderstood and misapplied patterns in the software ecosystem IMO. Jan 30, 2019 at 15:11
  • I thought as a MVP as a beta version of something... maybe one wants to assess (internally) if the game is good before sharping up each pixel. It'd be adding some sort of value, such as proving it's viability, right?
    – Tiago Cardoso
    Jan 30, 2019 at 16:46

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.



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.

  • I agree the goal should be to treat artistic work the same way as coding work, but it looks to me that nevertheless, having a vertical slice of a functionnality (without multiple DoD) is rarely feasible considering doing a character could take 2 months for example. Also, I like the idea of treating adjustments changes as new work. Do you have a reference about that point that I could read? Initially, I thought that as with code user stories, if the output doesn't answer the user's concern, it should not be accepted and the story should continue to be worked on.
    – David
    Feb 14, 2019 at 2:39

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.