With Scrum / user story / agile development, how does one handle scheduling out-of-sync tasks that are part of a user story?

We are a small gaming company working with a few remote consultants who do graphics and audio work. Typically, graphics work should be done at least a week (sometimes 2 weeks) in advance of the code so that it's ready for integration. However, since SCRUM is supposed to focus on user stories, how should I split the stories across iteration so that they still follow the user story model? Ideally, a user story should be completed by all the team members in the same iteration, I feel that splitting them in any way violates the core principle of user story driven development.

Also, one front end developer can work at 2X pace of backend developers. However, that throws the scheduling out of sync as well because he is either constantly ahead of them or what we have done is to have him work on tasks that not specific to this iteration just to keep busy. Either way, it's the same issue as above, splitting up user story tasks.

  • 1
    As for the GUI developer working much faster than programmers: The way to do that it for them to spend 50% of their time on the current iteration and 50% on the next. Ie they should be one step ahead of programmers by designing and preparing for the next iterations work. Commented Mar 4, 2011 at 19:32

7 Answers 7


This is problem of team cross functionality. Basic Scrum expects that each team member is albe to do anything - in some environments (like game industry) this is not the case. Succeeding with agile describes this on example of UI Designer. As descirbed in other answers there is nothing wrong when UI designer works one iteration ahead to discuss and prepare design for developers. You can use same approach for your situation.

But if you do this for each your specialized role you will lose main point of Scrum - visibility. If cross functionality doesn't work in your environemnt you should check another agile methodology - Kanban should work in your environment. If you want to learn more about Kanban I highly recommend this book.

Also there is special book about implementing Scrum in game industry but I haven't read it.

  • Several people have suggested Kanban as a viable option, I should look more into. It seems that user story isn't suited for my development needs for a gaming app. FYI, your link to Kanban book is on Scrum instead?
    – Bob
    Commented Mar 3, 2011 at 20:29

The challenge is this.

How to avoid being dogmatic and unthinking.

Agile requires flexibility. Not dogma.

However, since SCRUM is supposed to focus on user stories, how should I split the stories

Drop the "SCRUM is supposed to" mind-set. (Scrum is a word, look it up, not an acronym. It's a play in Rugby, everyone pushing in the same direction.)

Ideally, a user story should be completed by all the team members in the same iteration

No. There's not "user story should be" anywhere in any Agile description. You finish something that's releasable. That doesn't mean everything is done at once and magically arrives at the finish line together. Scrum means that at the end of a sprint you have something you could release. Maybe you have more. Maybe you have a raggedy list of things ready and things done early. It's all okay. Really.

Either way, it's the same issue as above, splitting up user story tasks.

Relax. Stop focusing on something Scrum is "supposed to be".

Break things up sensibly. Think about it. Talk amongst yourselves. Work out something logical.

Don't be dogmatic. Don't slavishly stick to some rote method. Stop. Think. Talk. Decide.

  • 1
    +1 for "Stop. Think. Talk. Decide." It's worth noting, however, there wouldn't be jobs for consulting in Scrum if it wasn't easy to screw up. :-)
    – corsiKa
    Commented Mar 3, 2011 at 0:50
  • Perhaps I should have just stuck with the term "user story" as opposed to also agile development and SCRUM. I agree that the goal is not to be dogmatic about agile development but there is a sensible process for user story driven development. However, the process is centered around completing user stories in their entirety within an iteration which includes complete front to backend including graphics, etc. If I don't follow that approach, then it's not user story based development and I should just not use it. SCRUM is a lightweight project management process that's not the same as user story
    – Bob
    Commented Mar 3, 2011 at 0:59
  • "the process is centered around completing user stories in their entirety within an iteration which includes complete front to backend including graphics, etc." False. It's about completing something deliverable. Extra front-end or extra back-end doesn't matter. "If I don't follow that approach, then it's not user story based development". False. It's still user story-based development. Without the dogma. Just sensible planning that allows for the variabilities in the deliverables. And SCRUM is still not an acronym.
    – S.Lott
    Commented Mar 3, 2011 at 1:36
  • @glowcoder: The only way to screw it up is to impose extra, dogmatic process. Do less. Release sooner.
    – S.Lott
    Commented Mar 3, 2011 at 1:37
  • 1
    @Bob: Here's the issue. I agree with almost everything you're doing. You're doing almost all the right things. The only thing I disagree with is your characterization of "chaos" and "violation of the process". That's a false dichotomy. The alternative to rigid adherence to a process is not chaos. You can have somethings done early. It's okay. The only thing I disagree with is your attempt to force fit your real-world complexity into a hypothetical text-book mold.
    – S.Lott
    Commented Mar 3, 2011 at 11:21

The purpose of splitting things into small stories and pursuing them in iterations is to get feedback on those stories more quickly, and limit work in progress.

In some Scrum teams I've been involved with, the analysts have been researching requirements for the next iteration while the development team finishes the current one. Your situation seems similar. I would do whatever seems most sensible and allows you to get the quickest feedback on the riskiest aspects of your work.

You may be interested in looking at some of the principles of Kanban, in which we use "cadence" instead of iterations, as this might help you co-ordinate. Kanban also focuses on reducing time for feedback and limiting WIP, so it's sometimes a good next step for a team which has outgrown Scrum. The Kanbandev list is on Yahoo, and I recommend David Anderson's book.

  • +1 - whether you choose to go with this or not, it's worth your time to check out Kanban/Lean. Visibility is extremely important.
    – TrueWill
    Commented Mar 3, 2011 at 1:57
  • Thanks for the suggestion, I'll check it out when I have a moment. I'm hoping there is an answer to my question using user story since that's what I'm familiar with currently.
    – Bob
    Commented Mar 3, 2011 at 2:08

We face a similar problem, because our work often requires external resources (cooperation from technology partners, or in-house resources such as a new server or a configuration change).

What we do:

  • We create tasks in the story for those external dependencies (like "Organize new server for load testing", "Run test with technology partner X", "Get new icon for button X"). We then try to start work on those tasks as soon as we start with the story, in the hope that it can run in parallel to our own work an be done when our work is done.
  • Sometimes the external dependency is ready in time, sometimes it is not. If it is not, we mark the story as "blocked", to indicate that we cannot continue work on it due to external factors.
  • We have organized our team board such that these stories stand out, and resolving the blockers is treated as high priority. Additionally, there is a list of blockers across teams, to give management an insight into areas where teams may need support.

Usually this work well, and a story is only delayed a week or two at most. If the delay gets longer, we try to split off the part that requires external resources, or find a workaround (like a default icon). If there is no way to get by without the external resource, the story just stays blocked.

This does mean that in rare cases a story stays open for months. This is ugly, but it accurately reflects reality, so we feel this is the best solution.

Note: We use Kanban, not Scrum, so there is no problem with meeting iteration commitments.


scrum is a way of really knowing that you are out of sync in a quicker fashion that you would do otherwise. hence here is a formula that I may suggest:

  • Every day when you begin work, call for a scrum
  • Get a check on who is where and if they are getting out of sync
  • Ensure you handle both scenario - someone is falling behind or surging ahead. Remember you do not want to stop someone who is moving fast. You need to get commitments from the folks who are behind on when they are going to finish up. And you need to ensure that the members who are surging ahead, have done tasks that align with the overall plan and dependencies

I don't think you should be looking at this as splitting tasks but splitting the story.

The story structure you are currently using should be an Epic. The create two children stories, one for coding one for graphic design and creation. Prioritize the graphic story above the coding story so that it would be worked at least two weeks prior to the coding story. When both are done the Epic is done.

The other issue is not as clean, I would suggest cross functional training and paired programming. In the short term it does not seem to make sense to have your 2x developer slowed down by working with less senior team members but after two or three iterations you will see a dramatic increase on overall team productivity

  • 1
    I think splitting stories like this is problematic. Completed stories should add value (if only by enabling feedback); if you split a story into graphics work and coding work, it looks like these do not provide value on their own. In that case it seems more honest and transparent to keep the story open until all tasks are done. If the story then runs for weeks, that's ugly, but a reflection of reality.
    – sleske
    Commented Sep 3, 2014 at 10:09

I think @S.Lott really captured the essence of the issue here, but considering Bob's desire to maintain the idea of user stories, @JDMyers answer is excellent. You want to break a problem down into manageable chunks, and if it helps to create parent-child stories, then do so. And cross train so every member knows at least a little about their areas of non-expertise. If your front-end guy has extra time, let him learn more about back-end technologies so he can help in that area. He's a member of a team, and the team is trying to achieve the goal (i.e., quickly releasing useable software) together.

As for user stories, remember, it doesn't really matter whether all tasks for a given story are completed or not during a given iteration. What matters is that your team is delivering what it's supposed to when it's supposed to (assuming realistic expectations are being set). Make sure the real problem is understood. Is it that a certain process doesn't seem "right", or is it that business expectations aren't being met? Agile and user stories aren't an end in and of themselves. They're a means to an end, namely delivering product in a timely manner. Refine your process so it supports your ultimate goal.

Not the answer you're looking for? Browse other questions tagged or ask your own question.