In our game project we currently have 2 teams that work in 2 week iterations. In the past we've repeatedly had issues with larger features (bad planning/estimates, unforseen issues before code freeze causing the stories to not getting closed, etc), and we've discussed those problems in many retrospectives.

Since the features we're supposed to implement are not getting any smaller or easier (actually quite the opposite), we've been thinking about ways to help us reduce the risk of each iteration. One such idea I had, was going with a setup similar to what ArenaNet does with Guild Wars 2:

[...] “And they’re all staggered, so even though we ship every two weeks, the development time for any one of these releases is around four months, it’s just that it’s a smaller team working for an extended period of time which allows them to give it the level of polish that players have come to expect. But it is intense!” [...]

The basic idea was to stick with the 2 week release cycle, but move the teams out of phase with each other, so that each individual team would have a total of 4 weeks to work on content. So basically, the setup would change from this: current setup
to this: new setup

Of course, the releases would be bigger than before, but at a first glance it seems at least somewhat beneficial:

  • More time to react to unforseen issues (bugs, system failures, bus factor, ad-hoc design changes, ...) without endangering the whole sprint
  • QA could focus on one team/feature/release at a time, instead of having to check everything from both teams at once
  • Ability to work on larger features without having to chunk/split them into artificial segments to fit the sprints

Now I wonder if this was actually a good idea, or if I'm missing something obvious and it would just screw up everything. Are there any other resources on this topic? Are async scrum teams workable, or is it generally just a bad idea?

  • 1
    How do you currently merge changes made by two teams at the end of each sprint? I can see you might have problem merging changes of one team into a development branch of another team in the middle of their phase, but it heavily depends on your merging policy. – scriptin Nov 1 '15 at 10:09
  • @scriptin: we're currently using Git, and work primarily on a develop branch. After code freeze, a staging branch is taken from develop and tested (with bugfixes going directly to staging). When QA approves the build, staging is merged into master and back into develop. – arotter Nov 1 '15 at 10:19
  • 1
    That's about what I expected. It works fine when you merge few relatively small changes together at the same time, and it is problematic when you have bigger changes. The common good advice is to merge early, often, in smaller portions. Think of a situation where bigger changes arrive in the middle of a team's dev cycle. I believe this is a recipe for disaster with this approach, because, while a team may already be short on time in the middle of a cycle, they also would have to deal with merging changes delivered by the other team. – scriptin Nov 1 '15 at 10:27

In the past we've repeatedly had issues with larger features (bad planning/estimates)

If you encounter planning/estimation problems just for two week sprints in advance, do you really believe this will get better if you now have to estimate your team's work for four weeks instead of two? Honestly, I think this will make things worse, not better (and it does not make a difference if your teams work synchronously or not).

Ability to work on larger features without having to chunk/split them into artificial segments

The need for splitting big features into smaller slices is IMHO a strength of the process - if you sacrifice this, your planning/estimation will become worse, your testing cycles will get longer and your ability to control the process will decrease. Thus I would heavily recommend against this. Better try to make the splitting of features not-so-artificial.

If you have bigger features to work on which cannot be completed in one sprint, split them up into smaller ones, but do not make those partly completed features available to your users immediately at the end of each sprint. Better, learn to utilize "feature branches" and "feature toggles" for your needs.

A better branching/merging strategy might also be an approach to untie your teams from the fixed "two weeks" sprint cycle - if the next feature slice fits better in 9 days instead of 14, whilst the other team needs 16 days, this should be perfectly possible. And your QA team can still get a new version every 14 days. You have to establish a strategy for this which allows you to prohibit the delivery of half-baked features from the development branch to "staging" in the middle of a sprint, without stopping your teams from work. There are different approaches how to accomplish this with Git, and of course, your configuration management effort will probably increase, but that is probably outweight by the benefits you get from this.

  • 1
    That's a really good question, and to be honest, I don't know the answer. Most of the issues we had was either underestimating the initial implementation effort of a feature, or overlooking some critical interaction with another system that required additional changes which became apparent in the middle of the sprint. – arotter Nov 1 '15 at 10:24
  • @arotter: The risk (and effect) of underestimating increases with the size of the task. That is another reason to keep your stories relatively small. It is recommended that you can fit about 5 of them in a sprint. That also makes it possible to drop on of them if the others turn out to be underestimated. – Bart van Ingen Schenau Nov 1 '15 at 16:34
  • @BartvanIngenSchenau: I don't think it's valid to day "it is recommended that you can fit about 5 of them in a sprint". There are just too many variables. My most effective team routinely did 4. Other teams who are good at splitting their stories or have work that naturally fits into one day chunks could do 6 or 8. Small teams might only finish two.. I don't think there's a good rule of thumb that is applicable to a majority of teams. – Bryan Oakley Nov 16 '15 at 13:51
  • @BryanOakley: I wrote it as a 'recommendation', but it is closer to a 'suggestion' than a 'rule'. The number 5 also isn't fixed but comes from the fact that if you have very many stories (>10) the board can become very cluttered and if you have very few stories (<3), then it becomes hard to react to disturbances/sickness/etc. by dropping a story from your sprint planning. I consider the first (many stories) to be less of a problem than the latter (very few stories). – Bart van Ingen Schenau Nov 16 '15 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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