5

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.

Bob
  • 153
  • 2
  • 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 04 '11 at 19:32

7 Answers7

11

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.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • 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 03 '11 at 00: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 –  Mar 03 '11 at 00: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 03 '11 at 01:36
  • @glowcoder: The only way to screw it up is to impose extra, dogmatic process. Do less. Release sooner. – S.Lott Mar 03 '11 at 01:37
  • @Bob: The process is not the objective. The release is the objective. Please let the process go and focus on building something you can release. – S.Lott Mar 03 '11 at 01:38
  • @S.Lott, true that the process is not the objective but it is designed to work in a particular way for optimal results. Otherwise it's pretty much development by seat-of-the-pants method which works up to a certain point but doesn't scale. –  Mar 03 '11 at 01:50
  • @Bob: "it is designed to work in a particular way for optimal results.". No. It's designed to make you think about what you are doing. It scales if you think about it. It doesn't scale if you dogmatically claim that there's an absolutely right way to do things. You do realize that your case is a complex "edge case" that's not well covered by **any** process or method? You have a particularly hard problem. The process gives you a sensible direction. Not a fixed script. Focus on creating something releasable. Acknowledge that your problem is actually hard. – S.Lott Mar 03 '11 at 01:56
  • @S.Lott, I am not dogmatically claiming that there is only one right way to do user story development, what I am saying is the core principle of user story development is that all the user story deliverables must be done in one iteration to deliver a desired set of user features. Violating that means I'm not doing user story development which is fine if that's what I decide to do but I can't violate that and still call it user story development. I don't think my problem is that hard or unique especially the one about graphics work done before actual development. –  Mar 03 '11 at 02:05
  • @Bob: "I can't violate that and still call it user story development" False. Actually you can "violate" that and still call it user story development. "I don't think my problem is that hard". It is, however, since your deliverables don't arrive at the same time. Relax. The method is designed for more "traditional" software like database and CRUD applications. It doesn't work "perfectly" for everything. It's there to make you think. It's not a fixed script. You're thinking. That's the point. It's not a "violation" to think an adapt. It's thinking. You're allowed to think. – S.Lott Mar 03 '11 at 02:42
  • @S.Lott, guess we'll agree to disagree, thanks for your feedback though. –  Mar 03 '11 at 04:07
  • @Bob: You asked for help. I'm providing you help. You can refuse the help quietly -- by simply ignoring it. Fighting against the help is wrong. You're doing too much process. You're doing the right amount of thinking. The point of Agile (and Scrum and story-based development) is to use **less** process. Not argue about the details of the process. Please read the Agile Manifesto a few times. http://agilemanifesto.org/ "Individuals and interactions over processes and tools". Please focus on your people and your deliverables. Please drop the process focus. – S.Lott Mar 03 '11 at 10:51
  • 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 03 '11 at 11:21
  • @S.Lott, with all due respect, just because I asked for feedback doesn't mean I have to agree with everything. If there is something fundamental I disagree with, I'll make my case as you did yours. I have also used other methodologies like waterfall and I have since decided that it is not a productive methodology and instead of trying to adapt it to what it isn't designed for, I instead chose to try out a new methodology that I thought is more befitting. Other comments suggested Kanban and it seems like a reasonable option to consider in my case. –  Mar 03 '11 at 20:26
  • @Bob: You're already doing almost everything right. You're question is simply stressing over an irrelevant detail. And then you appear to be arguing that this detail ("violation"/"chaos") really really matters a lot. Take a step back. You're doing everything right except for the trying to force-fit your real-world problem into a hypothetical model. – S.Lott Mar 03 '11 at 20:29
  • @S.Lott, like I said before, let's agree to disagree and move on because I don't agree that it is an irrelevant detail, it's the main reason why anyone would want to use user story. –  Mar 03 '11 at 20:33
  • @Bob Your question was migrated from SO here because it fits the scope of Programmers.SE better. S.Lott had nothing to do with that. – Adam Lear Mar 04 '11 at 15:56
  • @Bob @S.Lott I personally do not see harassment here, just an opinionated argument. If you both want to continue this discussion, please take it to chat. Otherwise, I think this has gone far enough. Thanks. – Adam Lear Mar 04 '11 at 16:29
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.

Ladislav Mrnka
  • 7,326
  • 1
  • 23
  • 32
  • 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? –  Mar 03 '11 at 20:29
4

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.

Lunivore
  • 4,232
  • 1
  • 18
  • 23
  • +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 03 '11 at 01: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. –  Mar 03 '11 at 02:08
1

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.

sleske
  • 10,095
  • 3
  • 29
  • 44
0

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.

squidbe
  • 101
  • 1
0

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
Sandeep Singhal
  • 101
  • 1
0

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

JDMyers
  • 109
  • 1
  • 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 Sep 03 '14 at 10:09