Scrum: How long should your Sprint be? Single vs Multi Scrum Teams
Did you ever notice that a lot of scrum teams are having two-week sprints? Is that the right thing to do?
A lot of people say we need to be consistent, we need to have the same sprint length so that we’re all on the same rhythm, etc.
I think there is a fundamental problem with that.
Why would you have every team having the same sprint? There might be some situations where that would be valid. The first thing I would say is, let’s just start with a single Scrum team.
A single Scrum team working on a product because Scrum is for product development, not so much for project management. This team is delivering a product.
How long should their sprint be?
Single Scrum Teams
I wouldn’t be going for the most popular sprint length. I would be asking a few questions, most importantly, how long does it take you to deliver a done increment?
How long does it take you to deliver a done increment?
Do you have a decent Definition of Done (DoD)?
In Scrum, we have a definition of done (DoD). This is like the checklist for how we do things around here. This includes the quality standards and maybe with elements of product quality in there as well. Technical standards and product quality.
Assuming a decent Scrum team has a definition of done, one which the team respects (because if they respect it, they can then have some hope of continually improving it), how long does it take them to deliver a done increment?
How long does it take them to deliver a done increment?
If it takes them three weeks, well, maybe you should have a three-week sprint. I do not see the point of having a two-week sprint for a team that needs three weeks to deliver a done increment.
If it takes you three weeks to get something to done (according to the definition of done) we do not want people taking any shortcuts with that. We do not want people building up accidental technical debt or making the product increment a lower quality. On that note, stick to how long it takes to deliver a done increment.
Does it take longer than 30 days to deliver a done increment? Make your product backlog items smaller, here’s how
Now, where it becomes problematic is where it takes longer than 30 days to deliver a done increment. In that case, I think you have got bigger problems than the length of your sprint. You probably have issues with the product backlog items that you’re taking in, they are probably too big. Then you probably need to be looking at some kind of splitting guides.
There are lots of heuristics out there in terms of how you can break some items down. Failing all of that, you can use example mapping from behavioral-driven development, where maybe you list out 25 examples for this product backlog item that will be needed by the time you go live. In response to people saying “We can’t deliver this in a sprint, it’s going to take six weeks, we can’t deliver it in 30 days”. I say “Can you just do the first example?”
“What do you mean? We know we have to do the second and the third example as well”.
“Yes, I know, but you can just do the first example?”
Let’s just get some feedback and see how we get on with the first example because the Sprint Review is like an event where people find out what they don’t want when they see it. People struggle to articulate what they want.
Consider example mapping as a technique to maybe get the item size a bit smaller so you can do things in 30 days. I had a chat with Tobias Mayer on the Xagility Podcast and he challenged me. He said we can always do something in 30 days. I think the man is right. I think you can do something in 30 days.
There’ll be some rare exceptions where that’s not the case. So one consideration is have you got a done increment? How long does it take you to deliver a done increment?
Dealing with Product Owners injecting change into the Sprint
Another consideration would be the product owner changing his/her mind about what needs to be done and injecting change into the sprint. Now, it is possible. You are allowed to bring change into a sprint. You are allowed to introduce product backlog items during the sprint, as long as you’re not compromising the sprint goal. But people don’t do that because normally we don’t have enough evidence to say that we’re not going to compromise the sprint goal.
So unless you are using Scrum with Kanban, you will not have the information to answer that question. As such, we tend to avoid bringing changes in during a sprint, and we probably want to keep it that way so the team can be focused, so they can get what they started finished and we can get some feedback sooner.
If you have a situation where you have a four-week sprint, you can deliver a done increment in three weeks and the product owner wants to put change in, if you change your sprint time from four weeks to three weeks, what you’ve done is you’ve changed the average wait time for a new sprint from two weeks down to a week and a half.
Ordinarily, I would say a product owner will probably be willing to wait a week and a half on average. It could be the wrong end of the sprint, in which case the spring goal might be obsolete and that’s a different story. I’ve only had one of those occasions in my career. So I would say the length of your sprint should be how long does it take you to deliver a done increment?
Other considerations for how long your Sprint should be
Also, maybe how long does it take you to do customer user research, maybe UX, and so on? Maybe you want to get some response from prototypes, interviews, all that kind of stuff. So there’s that consideration as well if you’re using Scrum with UX.
But for most Scrum teams who are not so much into experimentation (I wish more were into experimentation), then you would ask “How long does it take you to deliver a done increment?” and no shorter than that so that the product owner has maximum flexibility, so when new changes come in into the product backlog, there’s an opportunity to bring those into a sprint sooner because the next sprint planning is going to be sooner.
It’s not as straightforward as that though, because most of us don’t work in single-team products. We’ve got multiple teams working on the product.
What do you do then when you have multiple teams?
Well, the scaling frameworks that I am most comfortable talking about are Nexus and LeSS.
Nexus
In Nexus, if, say, for example, the overall product group had a four-week sprint, it’s fine for some teams to spin around inside that with a one-week sprint or a two-week sprint or for slower teams, a four-week sprint.
As long as you’ve got the same boundary that, in other words, the multiplication needs to work one, two, four, one, and three, they would work. So you could have faster teams spinning around faster within the Nexus Sprint.
Why would you have a team that could deliver stuff in a week, being stuck to a three-week sprint? Nexus allows you to do it that way.
Large Scale Scrum (LeSS)
On the other hand, in LeSS, the entire product group has the same sprint length. So if we all have a four-week sprint, every team has a four-week sprint, or they have a three-week sprint or two-week sprint. Whatever the sprint length is, we are all doing it at the same time.
That’s not a bad reason, you don’t want a situation where you come looking for help in my team and I’m not available because I’m in sprint planning for my team. That problem is avoided when every team does their events at the same time, including product backlog refinements being done at the same time in LeSS.
So there, I can see the upside of that where everybody would have the same sprint in that case, but I would hope that no team has a sprint length that’s shorter than it takes them to deliver a done increment. As such, be careful, I would say, about having this default position of just having two-week sprints because it’s the most popular sprint length.
Concluding Remarks
I think the first question you should be asking is, how long does it take us to deliver a done increment? It should be no shorter than that. If you’ve got problems delivering within 30 days, you’ve got bigger problems than the size of your sprint. You have got problems with your product backlog refinement.
Meanwhile, consider example mapping, consider maybe looking at the first example to break down part of backlog items so they fit into smaller sprints so you can deliver a done increment in a shorter period in 30 days or less.