Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

If someone can recommend an active Google agile development group that discusses these and other issues, that'll be great. Also, if you know of a free alternative to Pivotal Labs, let me know as well. I'm looking now at Agilo.

share|improve this question
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. –  Martin Wickman Mar 4 '11 at 19:32
add comment

migrated from stackoverflow.com Mar 4 '11 at 3:52

This question came from our site for professional and enthusiast programmers.

6 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
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 Mar 3 '11 at 20:29
add comment

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.

share|improve this answer
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 Mar 3 '11 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 Mar 3 '11 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 Mar 3 '11 at 1:36
    
@glowcoder: The only way to screw it up is to impose extra, dogmatic process. Do less. Release sooner. –  S.Lott Mar 3 '11 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 Mar 3 '11 at 11:21
show 12 more comments

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.

share|improve this answer
    
+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 Mar 3 '11 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 Mar 3 '11 at 2:08
add comment

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

share|improve this answer
add comment

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
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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