What is the Right Iteration Length

Episode 39

December 21, 2011




The Agile Week Crew discuss Todd Landry's article What is the Right Iteration Length

Episode Notes

Jade Meskill, Derek Neighbors, Chris Coneybeer and Roy van de Water discuss an article by Todd Landry titled “What is the Right Iteration Length”

Is it better to have a shorter iteration and close the feedback loop

Is it better to have a longer iteration to decrease the overhead of the Scrum Ceremonies?

Sprint Review seems to be the only ceremony not proportionally decreased with sprint length

Retrospectives do not have to occur every week, or perhaps have an extended retro every other sprint

The cost of deploying is sometimes an argument for longer sprints

Deployments and releases should be unhinged from sprints

The team agrees that shorter sprints are generally better


Jade Meskill:  Hi. Welcome to another episode of the Scrumcast. I’m Jade Meskill.

Roy van de Water:  I’m Roy van de Water.

Chris Conagher:  I’m Chris Conagher.

Derek Neighbors:  I’m Derek Neighbors.

Chris:  I was reading an article this morning by Todd Landry, called “What is the right duration length?” He was bringing up some experiences that he had in trying to discover what the correct duration length is. He says that when they first started forming an agile team, they were new to the concept. They figured they’d do one week iterations. They’d have a really quick feedback loop and be able to adjust as quickly as possible.

He says they did that for a little bit. They felt that the overhead of all of the scrum ceremonies for one iteration, got out of hand, so they increased it to two week iterations. He felt that that worked a lot better for him. He says around the holidays they started an iteration where they said, “Well, we can’t really do a real iteration, so we’re going to start now, and we’re going to end when the last person leaves the building.”

It ended up being about a four week iteration, and he says that that was a complete nightmare.

Roy:  Yeah, it sounds that way. I was about to unleash on that one, but…


Roy:  At Integrum we have done a lot of one‑week sprints, and you guys have all been a part of those one‑week sprints. What do you think, what was the positives from doing one‑week sprint?

Chris:  I think some of the positives were that the ceremonies were very targeted. We had to learn how to keep them under control. I think that’s something the teams go through is that they don’t do a good job of making sure they keep those ceremonies under control, and that’s why they get so much overhead from them.

Derek:  Yeah, I tend to agree. The number one thing that I hear from people is that the overhead on one week sprints is too high. The only ceremony that I believe has that amount of overhead is, really, the sprint review including the retrospective. The main reason that I say that is planning should be a rough estimate of a percentage of time in your sprint.

If you’re doing a four‑week sprint, you might spend an entire day. If you’re doing a two‑week sprint, you might spend a half‑day. If you’re doing a one‑week sprint, maybe you’re doing two hours. I think that what happens is a lot of teams doing one‑week sprint spend a whole day planning, and that’s where they feel the overhead is. I think they’re just being inefficient in how they plan. I, actually, think it’s poor planning that hurts one‑week sprints, not that there’s too much overhead.

We’ve played with this on and off. On the retrospective side of the fence, say, we’ll only do the retrospective every other week, or do a light version of the retrospective, where we at least catalog real quickly some high level frustrations, but don’t dig too deep. Then, on the opposite week, dig a little bit deeper, and spend a little bit more time during that.

From a demo perspective, which is really the other element of it, you should be demoing your work pretty much as you complete it. You shouldn’t be building up a whole lot of sprint demo time to begin with, so…

Roy:  I think there’s a lot of teams that don’t follow that particular piece of advice, where they’re demoing constantly.

Jade:  But even if they’re not demoing constantly, if they are only demoing one week’s worth of stuff, then their demo shouldn’t take the same length of time.

Derek:  I think another thing that kills people too is there’s this really bad stigmatism that you have to deploy when you have an end of a sprint. A lot of teams, deploying is very painful, and so that eats up a lot of time. It’s actually getting things deployed so that they can actually demo. It’s why I find, when there’s a poor build environment that, generally speaking, teams are less likely to want to do one week sprints, because the deployment for demoing takes up half a sprint.

Roy:  I always tell people that they need to unhinge deployment and releases from their sprints.

Jade:  However, I kind of feel like, if you’re doing the deployment every two sprints, then that kind of builds up a cadence. It does almost feel like it would make sense to…

Roy:  I think it’s nice, and it’s good if you can get there. But I don’t think they should be solely dependent on each other.

Jade:  I think in an ideal situation, you’re deploying as often as you’re demoing, which is daily, and you don’t have to worry about it.

Roy:  I think that’s a pretty highly evolved product or organization that can live in that continuous deployment world.

Derek:  I guess where I get really concerned is, I’m even OK, as much as I might bag on it, on a 30 day sprint, or a four week sprint, as long as a team understands that that’s a segment of where they’re at, not where they should be going.

I get concerned when somebody starts with a one week sprint and then pulls back to a two week sprint, and says, “For us, just a two week sprint works better.” Because what they’re really not acknowledging is all the problems that are keeping them from being able to do a one week sprint. I see teams do one week sprints all the time, really, really effectively, which means it’s doable.

If it’s not doable for your team, there’s probably other symptoms that are happening. Either you’ve got poor deployment practices. You have bad product ownership. You have poor planning meetings. A myriad of different things can be coming up that are preventing it from it.

Sometimes when people kind of roll back to this less‑than‑ideal state, if they don’t do it with a, “We’re only doing this for right now until we can get better at the other things,” then I think that that’s dangerous.

Jade:  I think that there’s some huge downsides, too, to doing one‑week sprints. I’m sorry. Downsides to not doing a one‑week sprint, specifically when it comes to regards to research tasks. If I’m doing commitment during planning and during my planning meeting, I find out that I don’t have enough information and I need to write research tasks.

If have a one‑week sprint, then it’s relatively low‑cost. I spend one‑week doing the research. In the following week, I can immediately do that task. If I have a four‑week sprint, that means I do the research task. That even means it’s four weeks until I do the research task. Then I don’t commit to getting it done until four weeks after that.

It’s going to be eight‑weeks until that story gets done. Or I do the research task immediately, but then it would be four weeks before I, actually, address the story. Then it’s four‑weeks between research tasks.

Derek:  But, if it takes you nine weeks to deploy, that’s all OK.


Chris:  Something that we’re talking about is that some of these teams that we hear when they’re doing one‑week and then they go to two‑week, how many times do we hear it’s right in the very beginning? You’re talking about retrospecting, realizing, “What do we need to change,” where they’re getting used to this, so it’s probably talking them longer than it would.

Are they really retrospecting, going, “Are we getting better at this? Can we stay at one week?” I have some questions in regards of what did the team think of and why did they go to two weeks?

Derek:  Too much overhead.

Roy:  I think it’s reduces that pressure like Derek’s saying. Doing a one‑week sprint requires a lot of discipline, and a lot of willingness to introspect and really pay attention to yourself. When you see people getting really uncomfortable with that, it’s because they’re trying to get a little bit more of a buffer to feel a little bit safer.

I think that’s OK in the early adoption phase. But like Derek said, if you just get stuck in that rut because, “Well, that’s just what we do,” I think that’s a bad place to be. You should really be trying to challenge yourself, but I think that’s reserved for teams that are a little bit more mature.

Jade:  With longer sprint‑sizes, you’re increasing the risk in a self‑organizing team. Because when a self‑organizing team comes up into retrospect, and comes up with an idea and they try it, in a one‑week sprint, they can cancel out that new thing to try within one week. But if you have a four‑week sprint, you’re stuck with that for four weeks. That can be devastating to the company.

Roy:  You could also do retrospectives disconnected from your sprint.

Chris:  That’s true.

Derek:  I think, as an industry, most people are doing two‑week sprints. I don’t know many people that are really on a 30‑day or four‑week cycle, but one thing I’ll say that I noticed wit