We are game developers and just began our Scrum practice. We found something like this:

During a sprint, we have several user stories to complete, but some of our members' work is not fulfilled. At the same time, someone may work overtime to complete them. This is basically caused by role differences, like artists vs. programmers, etc. For example, we have enough artists but not enough programmers, so that when programmers are working hard to death, artists may find themselves having nothing to do. So ok, I think saying that "caused by role differences" is wrong. More precisely, it is caused by lack of people of certain professions. Of course we're hiring, but how to get this through now?

Our solution now is to create small user stories dedicated to the people whose work is not fulfilled, like "concept art for character X", but apparently it is not a normal user story for us. Why abnormal? Because usually our user story is kind of "make character X", which includes concept art, animations, feature implementations, etc. "concept art for character X" is just too small and not on the same level of detail here.

So what's the best practice to deal with this kind of situation?

  • 2
    "This is basically caused by role differences, like artists vs. programmers, etc." Caused how? "But apparently it is not a normal user story for us." What makes it abnormal?
    – Sarov
    Commented Feb 3, 2017 at 4:37
  • @Sarov hey sarov, I've edited my post to answer your question, you can take a look at it :-)
    – Peter Ren
    Commented Feb 3, 2017 at 9:23
  • 4
    Scrum has uncovered a problem in your team, which is that you have too little of one capability and your team aren't t-shaped enough to adapt. The problem with a story like "create concept art" is that it's just inventory creation to keep people busy rather than value delivery. Before people answer, is there any scope to improve the programming skills of the more tech-inclined designers or is there a hard separation?
    – Nathan
    Commented Feb 3, 2017 at 9:48
  • @NathanCooper It depends. For artists and programmers, there is definitely a hard separation. However, for designers and programmers, it is possible to improve cross-functional skills of some clever guys, but it needs practice and a lot of time and we are working on it. Is there any advice before we make it happen?
    – Peter Ren
    Commented Feb 3, 2017 at 10:28
  • 1
    Labelling "concept art" as busy work is absolute nonsense and undermines any understanding of products. Seriously. There is a world outside of software engineering and it requires particular skills. Would you describe security as busy work? We would end up in an infinite loop where anyone not manipulating assembly language is simply doing busy work. Commented Feb 3, 2017 at 13:39

3 Answers 3


Unpopular opinion

Scrum is not wholly suitable for game design and development due to numerous factors.

  • Definition of Done can extend from 2 to 6 versions


  • Senior game developers like John Carmack (Doom) have rejected Agile/Scrum as a delivery method for game design and complex software engineering


  • The aim of Scrum is to produce a valuable working product increment every timebox that is potentially releasable

Game development does not work in this manner and certainly not within the smaller timeboxes that Scrum prescribes (1-4 weeks).

If you cannot potentially ship the product increment you cannot be doing Scrum. You are doing something and it may be Agile but it is not Scrum.

Scrum was originally designed for small cross-functional teams that had absolute minimal dependencies and could deliver value incrementally; improving as they went.

Producing a game does not fit well within that framework and certainly not within arbitrary timeboxes. The entire process has complex inter-dependencies between product, operations and technical activities including, but not exclusive to, direct customer feedback. Narratives need decided before level design can be implemented. Level design is required before AI and environment specific variables.

It is more akin to producing a movie which cannot be accomplished in a Scrum manner.

  • 1
    A scrum answer is that "It’s “shippable” to friendly users" is value and that there are shippable steps between start and a character being shiny and finished. Scrum based game development sounds like it would be full of a lot of spikes as well, but that's okay.
    – Nathan
    Commented Feb 3, 2017 at 13:58
  • Friendly users? Where is that in the Scrum Guide? I cannot find it anywhere. Here is the Scrum official guidance "At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it." Clearly a game cannot be released. This is without even getting into realms of Alpha and Beta testing. Commented Feb 3, 2017 at 14:42
  • 3
    I've actually witnessed agile game development as a user. The co shipped a MVP as an alpha, then released an updated version once or twice a month until they finally released the game on steam. It was kind of fascinating to see them iteratively build the game to its "final" state as a player.
    – RubberDuck
    Commented Feb 5, 2017 at 14:28
  • Agile game development is not Scrum game development. Scrum is a specific framework with specific rules, cadences, ceremonies and artifacts. Agile is a set of values. MVP is not a Scrum artifact. It is a Lean Startup artifact. Lean Startup and Scrum are different beasts. Commented Feb 6, 2017 at 16:45

Your team doesn't contain the skills you need. Ideally, everyone should be able to have some level of flexibility to step out of their particular specialism and take on the tasks to push the sprint forward. You may have come across the phrase "T-shaped" people. Scrum isn't wrong or unhelpful, it's just honestly pointing out a problem you have.

Fix your underlying problem: Everyone doing everything isn't necessarily attainable, but it should be your idea. Train your team: help your non technical staff acquire technical skills. Not everyone needs to learn to code to help out. Programmers also do a lot of stuff that isn't coding, checking logs, deployments, even doing basic IT help for their colleagues. Hiring more programmers would help as well.

Deal with it in the short term: It's important to remember that your job isn't to keep people busy but to deliver value. By creating art assets you may just be creating 'inventory' (lean people hate this) at a higher rate than your team can clear. it's not worthless, it's just not super valuable.

I would ask yourself this question though. Do you maybe have something actually valuable that could be delivered without much programming effort?

I don't think your example, concept art, necessarily is inventory however. I do see some independent value in being able to user test, distribute and market these new characters. As well as thinking about how to deliver valuable stuff, it's also useful to think about how to get the value out of the stuff you do deliver.


Scrum doesn't really work well for software with different disciplines waiting on each other. Scrum teams are expected to be cross-functional, but also should also be balanced so that the whole team can work in a sustainable pace. Working overtime is never a good idea, this will only hurt you on the long run. Tired developers have a netto negative productivity and they will just create a mess that needs to be cleaned-up in the days to come.

I would suggest using Kanban and visualising your current workflow. This to find your bottlenecks. Are you sure you need more programmers? Do you really need all that art work implemented? Maybe decrease on the artists instead. What do you really need? YAGNI!.

Personally I like the roles of Scrum and also the inspect and adapt meetings. Some teams then also combine Scrum and Kanban into ScrumBan. This just removes the iteration period where you forecast what work will be completed in 1-4 weeks, planning is more just-in-time. It will more be a flow of work continuously being completed.

This might still lead to work being stuck in the development phases, but at-least it will be visible. Also you do not have the disappointment and demotivation of uncompleted sprint after sprint.

Use regular retrospectives to trigger the team to optimise their own process, maybe they can figure out something on their own. Keep experimenting until you find the correct balance.

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.