On my first Scrum project, we started with only one team. That project soon grew to three teams, with the typical dependencies between them. I quickly arrived at what I thought would be a good way to manage those dependencies. I would stagger the sprint start dates by a week. The idea was that when a team went to start its sprint it would know the stories one of the other teams had recently committed to and which stories the other team was likely to finish.
Well, that part of my plan did work out well. But, overall, staggering the sprint start dates was a horrible idea. The biggest flaw in overlapping sprints is that there is never a time (except the end of the project) when all teams are done. One or more teams are always partway into a sprint. Some are planning a new sprint, others just planned a week ago, and still more teams will plan next week. This makes it difficult to give the full system to a customer for feedback or to an operations group for deployment.
A better idea is to have synchronized sprints, where all sprints end within a day or two of each other. Notice that all sprints do not necessarily need to end on exactly the same day. It is acceptable on a large project to have sprints that end over a two- or three-day period. In fact, there can be advantages to doing this. Allowing sprints to end over a two- or three-day period can make it easier for someone on multiple teams to attend all the review and planning meetings expected of someone on multiple teams. Additionally, it has the advantage in many cases of better accommodating remote team members who may travel into town for these meetings. A remote team member who is on multiple teams will find it easier to justify the travel time and expense if she can participate fully in each of her teams’ meetings.
Having synchronized sprints also does not mean that all teams must work in sprints of the same length. A project with multiple teams can accommodate different sprint lengths through the use of nested sprints. The most common use of nested sprints is when the various teams on the project cannot agree on a common sprint length, with some wanting two-week sprints and others wanting four-week sprints.
Don’t be tempted to overlap sprints. Instead, on multiteam projects, synchronize the sprints for maximum effectiveness.
More on sprint planning and scaling Scrum can be found in Succeeding with Agile.
Tags: large projects
We have done both ways in the last 18 months and we came to the same thought. We have stuck with 3 teams ending over 3 days. Great article Mike.
All for synchronised sprints but also for synchronised sprint numbers / names too.
I worked on a nine team project and like you mike many teams joined later and each team started their work their sprint counter started from 0. We did not see it as a issue until you started discussing the big picture and then you got something like “it will be done in sprint 4″, ” ah your sprint 4 in my sprint 13 and the other teams sprint 6″. It used to make your eyes water just thinking about it. We went to a consistent naming convention based on the month and the first or second half of the month. This work really well for us.
Thanks, Derek. I think almost every company tries (or at least considers trying) to overlap sprints. Almost all realize it’s just too hard.
Hi Mike–
I was thinking about sprint names/numbers myself a few weeks ago. How to refer to a sprint used to be such a common question. Quite seriously, this was one of those standard questions that I could count on coming up at *every* client I visited.
Oddly, I don’t get the question much at all any more.
I’m with you on consistent naming tied to the month. This has teams say things like:
–The June 10th sprint
–The first June sprint
–The second June sprint
–The early June sprint
–The late June sprint
which really help reduce confusion. Thanks for bringing this up.
Hi Mike,
I wonder whether needing synchronised Sprints to get to Done is a smell? Why can the customer only get a full system at these points? Is there some impediment or dependency which is stopping the flow?
I agree that synchronising Sprints is a good way to establish a cadence between teams in the short term. I’m not sure I’d recommend never being tempted.
Karl
Hi Karl–
It’s good to hear from you.
Each team in the specific case that prompted my post could quite easily get to done on its own with any sprint schedule. The challenges were things like getting stakeholders to come to sprint reviews when they were happening all the time. When teams synchronize their sprints, there is always the chance to combine a few sprint reviews (“your stuff only makes sense if they see what we did this sprint; let’s do our reviews together”). Even when sprint reviews aren’t combined, getting some busy, senior person to walk over here for a 45′ minute today, then another tomorrow, can be hard. It’s often easier to get someone to join one longer meeting. (Plus with one meeting, we can save money buy food only once
Plus, getting one release every two weeks (rather than 3 during that period) was, of course, preferable to customers. I’m looking forward to Office 2010 for the Mac but I’m not looking forward to a January release of it, then two in February, one in March, etc.
I checked above and didn’t say to never be tempted by this. I only used “never” when saying that if teams overlap (instead of synchronizing) there is never a time when everything has stopped and we can take a full snapshot of where we’re at. To me the benefit of this is like one of those families with on-the-go parents and kids who say “Do what you have to but everyone is home at 6pm for dinner.” We all go our way during the day (work, practices, friends, whatever) but it all comes together once per day (sprint). That’s one of the reasons why I doubt I’ll ever abandon iterations as a fundamental part of how I do software.
My company has been running Scrum for several years and we have syncronized sprints, meaning that they all start and ends on the same dates. We have 9 teams and a challenge we had was to get the stakeholders to attend the reviews (which ran over several days).
A while back we put all reviews on one day, in the same room, approx. 25 minutes per team. In my opinion this has been a success we have more stakeholders attending the reviews, it’s easy for teams to attend other team reviews making our development more transparent through the organisation.
BTW we do synchronized releases as well.
In our company where the system we build is very large and complex, synchronization is hard. On the other the size of the system forces us to big bang releases that happen 3 times a year (x3=9, for each supported version). The internal chaos around the release sprints is almost too large to be handled. This is why we’ve had to keep the sprints in sync.
Our clients needs vary so much that there are several recognized delivery patterns from which we have chosen the most poorest from the development point of view. Release seldom and release late. Which then goes against Scrum itself.
Thus I have started to think that by liberating the teams from synchronization we could force a refactoring of our delivery processes and make system components less interdependent. This would lessen the time to market and overall quality. And speed up the release cycle. Removing teams from sync could have positive effects when the company structure and/or old habits prevent making things better.
Hi Eirik–
This has been my experience as well. Thanks for sharing your story.
Hi Angry Poodle–
(I never thought I’d say that
You raise an interesting point. I wonder if synchronizing sprints creates unnecessary coupling between teams. I’ve never noticed this but I haven’t been on the lookout for it occurring because of synchronized sprints. I’ll start keeping an eye out for it. I don’t think, though, that forcing sprints to end at (about) the same time will create unnecessary coupling, but perhaps…
What I’m really after with synchronized sprints is to have a period where nothing is partially implemented. I want everything stable periodically so people can go hands-on with the software and know that if they find a bug, it’s a real but and not something that is there because Team #43 was only halfway through their sprint when we took the snapshot of the system.
We have a system that consists of roughly 100 productized components. We simply can not be stable at one single point of time due to the lack of resources and complexity of the system. Thus we dedicate few sprints for releasing where the system is freezed to a certain state before the release.
This way we force the syncing of teams, but we still have too much dependencies. Removing the sprint synchronization could be a tool to remove technical debt from our products.
But after the technical debt is swept away, keeping teams in sync is a worthy idea.
Hi Mike,
I really like your thoughts on this. We’re facing a similar problem at my company, and synchronizing teams could be lifesaver.
Although, what do you suggest happens in the case of sprints that are terminated prematurely? Let the team do a couple of weeks cleanup, or start a short sprint to catch up with the rest of the teams? Either way terminating a sprint can seem a bit more intimidating than it maybe should be.
/RB
Hi Rune–
Oh, great question. I should have thought to mention that situation in the blog post. If one team falls out of synch with other teams (on the same project) because of an abnormal termination, that team should run a slightly shorter or slightly longer sprint the next time. This will get them back in synch with the other teams. Normally it’s pretty easy to decide if it should be shorter or longer.
For example, if we’re doing 2-week sprints and abnormally terminate with 4 days left, the team do a 14-day sprint (2 weeks + 4 days the third week) to synchronize back up. Or if we’re doing 4-week (20-day) sprints and abnormally terminate 3 days into the sprint, I’d suggest planning a 17-day sprint.
[...] Synchronize Rather than Overlap Sprints – Mike Cohn explains why aligning Sprint end dates within one or two days of each other is a much better way to coordinate multiple Scrum teams. [...]