How long should a Sprint be

Podcast Ep. 143: How Long Should a Sprint Be with Dan Neumann and Sam Falco

How long should a Sprint be
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

This week, Dan Neumann and Sam Falco are together to talk about Sprint duration. A common question is “How long should my Sprint be?” followed by the classic consultant answer… “It depends.”

Today, Dan and Sam are sharing the definition of Sprint and how you can decide the right length of a Sprint for your team. They explore different Sprint durations, from less than a week up to a month, and how to pick the one that benefits everyone on the team.


Listen on Apple Podcasts

Key Takeaways

  • What is a Sprint in Scrum? 
    • Sprints are the heartbeat of Scrum where ideas are turned into value
    • The whole idea of a Sprint is to create a done increment
    • All of the work that a team needs to do has to take place inside of the Sprint
    • All of the work that needs to be done to get to the product goal has to be done in Sprints
    • Scrum is not a task management system
  • Is there a supposed length for a Sprint?
    • Most commonly a Sprint is thought to be from two to four weeks long. Keeping the duration of Sprints consistent is recommendable because part of the reason for timeboxing is to help Scrum teams predict what they can do
    • The scope can vary in a Sprint, as long as the team is aware of their Sprint goal
    • According to the Scrum Guide, a Sprint can be ‘up to one month long,’ in spite of the common idea of two to four weeks
  • Balancing flexibility vs. stability
    • The Leave-you-alone principle: A Sprint is an agreement between stakeholders and the Scrum team, where the first party agrees to leave the Scrum team alone to do what they require them to do
    • One of the principles behind the Agile Manifesto is the idea of sustainable development, the sponsors, developers, and users should be able to maintain a constant pace indefinitely
    • A business can shift entirely at the end of a Sprint, but within the Sprint let the team work towards a goal. If there is an urgent need to change, the Sprint can be canceled, which is tremendously costly and needs to be avoided if possible
  • Different levels of projects determine different Sprint durations
    • Do not forget that a team’s priority is to deliver early and continuous software delivery
    • Dan and Sam share examples of ten three-day Sprints and one-week Sprints to achieve more focus on the goal
    • Two-week Sprints are the most common ones but it might not be a good length for everyone in all domains, especially depending on all the stuff that needs to be done
    • Automated testing is a great way to save time
    • A three-week Sprint does not align with the 52-week calendar, what should you do with the extra week every month? Defying the tyranny of the calendar can be fun and motivating
    • The month Sprint can be tricky if the client, thinking that there is plenty of time, starts asking to add or change elements
    • Ask yourself: Does your team need more time to innovate? Are you cutting quality as a result of rushing towards the goal?
    • Pick the shortest Sprint length possible for your team to start with since you can always relax that a little later on the journey if it needs to be that way

Mentioned in this Episode:

Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]

Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host coach and agile expert, Dan Neumann.

Dan Neumann: [00:16]
Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host, Dan Neumann, and joined by very regular guest, Sam Falco, principal trainer at AgileThought, how are you doing Sam?

Sam Falco: [00:28]
I’m doing well. You?

Dan Neumann: [00:30] I’m doing super.

Sam Falco: [00:32] Wow.

Dan Neumann: [00:32] Cause you’re wearing a Superman shirt. Thanks for asking.

Sam Falco: [00:41] All right, so we’re off to our usual rollicking good start.

Dan Neumann: [00:44]
We are off to, I start, uh, I was going to take us into a little bit of a conversation about a metaphor that came to mind, but I think I’ll actually spare people that because I’m afraid who might not recover well, just leave the super for now. Oh, and today we’re going to be today’s exploration is going to be on the topic of Sprint duration, Sprint length.

Sam Falco: [01:08]
Right. I get this question in my PSM classes a lot. How long should my Sprint be? And the answer is the classic consultant answer. It depends. Right.

Dan Neumann: [01:22] I use, I used that yesterday. I was very proud of myself.

Sam Falco: [01:27] ,, I’m reminded of a story. Uh, Harry Tr,an saying he wanted to get a one-armed economists because economists always said on the one hand, but on the other nice. Yeah. I don’t know if that’s true or apocryphal or not, but let’s talk about Sprints and Sprint length. I think it’s important to first to start with what, what a Sprint is, why we’re doing this and talk about some of those fundamentals before we get into, how do you decide what Sprint length is right for you? Cause this is always contentious, ,, with organizations wanting things fast and developers saying, well, hold on, we’d like to actually test things before we hand them over to you. We’re going to need more time. ,, so there’s already, uh, a tension there. So this leads to the question. How long should my Sprint be? Because there’s tension between the business wants to get stuff now and Scrum teams need time to deliver the stuff. And that time there are a variety of factors that go into keeping track of that. So let’s talk first about what a Sprint is in Scrum. And I will just quote from the Scrum guide. Sprints are the heartbeat of Scrum, where ideas are turned into value, just nice poetic language from Ken and Jeff there. I thought that seems straightforward.

Dan Neumann: [02:55]
And yet it’s spurred a herd of coaches and trainers, Scrum masters and roles. But, but it doesn’t seem that hard. And it doesn’t that phrase nearly turned something into value.

Sam Falco: [03:06]
Yeah. That, but that phrase yeah. Where ideas are turned into value, I think is new to the update that came out in November. And that’s why I was saying it’s kind of poetic in a way. Uh, we start with just this idea. We have nothing and we turn it into something that we hope has value. So the idea of a Sprint, the whole point of a Sprint is to create a done increment, an increment that is usable, that is useful. That potentially has value. Don’t know why I st,bled over the word value there, but you know, it’s early. That meets the team’s definition of done. We say potentially shippable, that language has been moved out. Cause that caused all sorts of argy, bargy as people who just would argue what potentially shippable is, uh, I had a developer one time said, well, buggy is potentially shippable. We could ship that.

Dan Neumann: [04:02] It happens all the time.

Sam Falco: [04:03] Right. Right. Uh, so the new language is that it’s, it’s usable and it’s important to keep in mind that all of the work that we need to do has to take place inside of the Sprint, not a testing Sprint or a development Sprint followed by a testing Sprint, or God forbid, I’ve seen, well, we’ll have a design Sprint and then an analysis Sprint, another development Sprint, and then a testing Sprint. And I’m like, so you’re doing waterfall. Awesome. That’s not actually delivering value in a Sprint. We do all of those activities that are needed to turn that idea into value inside the confines of Sprints. And it’s also important to note that the new Scrum guide introduced the idea of a product goal. All of the work that we need to do to get to our product goal is done in Sprints, not phases. We don’t know about phases in Scrum. We just have our Sprints.

Dan Neumann: [05:03] So product goal, the long range thing, right? Sprints are steps towards that product goal. Each Sprint goals, hoping, hopefully taking you closer to that product goal. And within each Sprint, we’re looking to turn some ideas into an increment of value.

Sam Falco: [05:19] Right. At least one increment.

Dan Neumann: [05:21] At least winning, correct. There can be many increments within a Sprint. I love that the mindset about turn ideas into value.

Sam Falco: [05:29] That’s what it’s all about. And this is what kills me. When I see I’m going to go off on a little rant mini rant here, uh, tangentially. One of the things that drives me nuts is when I see organizations treat Scrum as a task management system, it is just a way to shove a bunch of work unrelated onto a group of people. They call a team, but everybody’s working individually so that they can manage their tasks. That’s not what it’s about. It is about turning ideas into value and a product that we can take to market and rent. So my point there, I hope you can help me get back to it as you always do.

Dan Neumann: [06:08]
Well, we’re actually, I was, uh, I was thinking of what you were talking about with the task management and ,, the phrase, well, sometimes Scrum just gets in the way and I’m like, ah, no, not if you’re doing Scrum well, not if you’re actually trying to turn ideas into value, if you are using it as a task management thing. Sure. Scrum stops to stops adding any value, but collaborating with your customers and tracking software frequently inspection and adaptation, you know, continuously improving all of those things in the agile principles are present in the Scrum framework. So yes, Scrum is a task management system you’re failing somehow. Scrum has, yeah.

Sam Falco: [06:52]
It’s not the right tool for your job. So maybe it’s not that you’re not doing Scrum well, but that you’re just not using the right tool for what you need to accomplish. If that’s really what you need to do is get a bunch of tasks through the system. Don’t use Scrum.

Dan Neumann: [07:07] Use a different approach. So, so we were talking about setting some groundwork for the Sprint. I feel like we should get off to the Sprint duration part.

Sam Falco: [07:15] Whenever I teach a class, I will ask students what length a Sprint? What does the Scrum guide say about the Sprint length? And very often they’ll say two weeks, instantly two weeks. And there’s some material out there floating around the interwebs. Let’s say two to four weeks. That’s an interpretation with the Scrum guide actually says it’s one month or less and suggests that it is best. If you keep the duration of your Sprints consistent from Sprint to Sprint. Because part of the reason for timeboxing our development effort is to help developers, Scrum teams, sorry, you can tell I’ve still got old Scrum language stuck in my head a little bit to help the Scrum team predict what it can do. And if you constantly change the length of the Sprint, it becomes a lot more difficult to conceptualize. This is what we do in a Sprint. So whether your Sprint is a week, two weeks a month, whatever it is, keep it consistent because after a while teams get together and they start figuring out, oh, this is the amount of work we can probably do in this amount of time in general. So consistent duration.

Dan Neumann: [08:30] Because often teams do well. We’ve got a lot of stuff to do. Let’s make the Sprint bigger. Like that’s not an unusual request and it’s not unique to any one place I’ve ever been. Right? It’s oh, we have, we have a lot. We should do a longer Sprint. We have a big story. We need a longer Sprint.

Sam Falco: [08:46]
We have a big story or the business wants more stuff. But remember that the idea is that a Sprint is to create a done increment, not to get a lot of stuff done that we should be and I’m kind of previewing where to talk about later. A Sprint is a project. If you think of it, that way that we are trying to accomplish a discrete goal within a certain amount of time, that helps you avoid cluttering it up with other things and also makes you think about, well, what can you actually do in a certain amount of time, but we’ll get back to that.

Dan Neumann: [09:18] Okay. So regular cadence helps people learn how much can be done in a Sprint, whatever duration, anywhere from one month or less. Okay.

Sam Falco: [09:28]
Right. And that we have to, as I said earlier, I think I said this while we were rolling tape. Uh, or maybe it was before we started. But, uh, it is we’re balancing the business’s need for, for getting stuff out the door and the Scrum teams need to spend time actually getting stuff done. So what’s our acceptable planning horizon. What is an acceptable amount of time for the business to wait in order to get new functionality, new, new, new product, new increment out the door. ,, and what we are doing though, there’s always the classic iron triangle of project planning, right? You can, you can hold, uh, time. Uh, you can have time scope and, and quality. You can hold two of those constant, but you can’t hold all three of them. Something’s gotta, something’s gotta give. In Scrum, we hold time constant with the Sprint is whatever length we have chosen. That is when we’re at the end of that Sprint, we’re going to have delivered at least one increment. And we hold quality constant in the form of our definition of done. We do not sacrifice quality. So then what has to be able to vary is scope. So scope can vary within the Sprint. As long as we are aware of our Sprint goal, make sure that you don’t sacrifice that you can add scope, remove scope, but make sure that you hold your Sprint goal constant.

Dan Neumann: [10:57]
Yeah. And that, that definition of done doesn’t mean that every desired bell and whistle is in there, it means the bell end or a whistle or a strap to hold the whistle. Whatever the valuable increment is, is a good one. There’s there will be more to do later.

Sam Falco: [11:14]
Fully tested thoroughly, thoroughly tested it’s as Bulletproof as you know how to make it. That’s really what a definition of done is about. And it’s been a couple of years, but we did talk about definition of done two years ago. I think we’ll put a link in the show notes for that. But that’s what our, what our quality goal is, is, is encompassed in our definition of done.

Dan Neumann: [11:39]
I like that. So as we’re talking about the Sprint, like ideas turning into value, Sprints are essentially a project and we’re trying to get a high quality increment done, right. The product. Good. ,, so you sent our definition of done and those things are factors that in picking the Sprint duration.

Sam Falco: [11:59]
Yeah. Yeah. We’ll circle back to that. Let’s talk a little bit about balancing flexibility versus stability, which was I was talking about of the business needs stuff fast and the Scrum team needs time to actually deliver something. And this is what a Sprint is. This is the agreement between stakeholders and Scrum team that says, uh, the Scrum team is saying, this is something we talk about in the professional Scrum master class that I teach. The Scrum team is telling the business or the stakeholders, every Sprint, you can have us do whatever you want, whatever new thing that you want, as you see fit, whatever you think is most valuable, we’ll do that for you. The business is then saying great. During the Sprint, we will leave you alone to work on what we just told you we need you to do. And we won’t constantly be changing our expectations. This is a principle that is often not honored. The leave you alone principle. ,, well I’ve actually seen some Scrum teams push back on. Well, we don’t want to change from Sprint to Sprint. We, we want, you know, we, we want to essentially roll forward what we were working on last Sprint don’t change direction because we didn’t finish it. And that’s another thing that that can happen is the team feels too much pressure to bring too much in, then things roll from Sprint to Sprint. Or if a team does not have the discipline to deliver on their promises, sometimes they get this idea that it doesn’t really matter if we finish it or not, because we can just push it to next Sprint or roll it to the next Sprint, whatever the, the language is. But yeah. Part of the agreement, right? Part of the agreement is the commitment that the Scrum team is making to the business. If you leave us alone for one month or less, whatever our Sprint length is, we will deliver good working product to you that we hope you’ll be happy with. And we’ll get your feedback that is as good as we know how to make it. Not we will tell you we’re going to do some stuff. And then at the end of the Sprint, we’re going to go, well, we didn’t really do it. Yeah.

Dan Neumann: [14:17]
So the Sprint review is not a chance to just pulse on how much of the hours we burn, how much activity what’s done and what’s not done and where we’re going, you know, it’s, here’s the increment, right? Yeah. The Sprint goal is met.

Sam Falco: [14:36] Yeah. It’s not, as I said in a previous podcast, not just chewing your way through a backlog, it is distinct. We are delivering something of value each Sprint. Here’s what we’ve got because the business needs that flexibility, right? The, the market is going to change. And this is the problem with the older, more traditional more traditional, I mean, Scrum is pretty traditional at this point. Let’s say pre-agile frameworks, methodologies processes like waterfall, like, uh, some of the other big design upfront is the idea that we can predict and plan a year or more in advance. And the market won’t stand still for that. So the business needs to be able to go, Hey, the market just changed and we need to shift with it. Or we see a way to lead the market and force our competitors to catch up with us. We need that flexibility. And that’s what the Sprint gives us.

Dan Neumann: [15:30] So there’s, so there’s two factors there. There’s one. How, how rapidly does the business, you know, want increments little bits of delivered project or little projects delivered? I shouldn’t say bits of projects, little projects delivered. And then how long can the business maintain, focus without going, Hey, Hey guys, guys, new shiny object. We want a new shiny object. And this where, you know, a month sometimes seems like an eternity from a business standard. What do you mean? I can’t get a new shiny object in the queue for, you know, three and a half more weeks.

Sam Falco: [16:02]
Right. Which is odd often coming from the same business. People who want to do year and a half long plans, but they want to change right now.

Dan Neumann: [16:11]
So there’s, that is a whole separate thread probably.

Sam Falco: [16:13] Right. Right. Thank you for keeping me from going off on a tangent, but I want to bring in one of the principles behind the agile manifesto is the idea of sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. And that does not mean we go flat out. We’ve talked about this before, but that we have to figure out how often can the business accept new releases and how long, how often can your customers accept new releases? Because a business that says we need a new shiny object every month, and the customers are saying, we’re only going to accept a new update every six months. Well then you need to evaluate that. But while the business needs the flexibility, then again, our Scrum teams needs stability because if they are constantly being kicked from idea to idea and not given an opportunity to really come to grips and finish anything that leads to all sorts of horrible problems, low quality, it leads to well, the task switching alone kills productivity leads to burnout is to unhappiness, uh, and can really affect things like attrition. And you want to avoid that, so we need to limit major direction changes to the Sprint boundaries, right? The business can shift entirely at the end of a Sprint, but within the Sprint, let the team work towards the goal. And if you really, really need to change, like if something goes completely awry, we do have the mechanism of canceling the Sprint. The product owner is the only person who has the authority to say, you know what? That goes obsolete. There’s no point in working on it anymore. Let’s cancel the Sprint and immediately plan a new one and start over. That’s incredibly costly. You don’t want to do that a lot. In fact, I’ve only seen it happen twice in my career. Since I started with Scrum in 2008, I think it was twice. And one of them was because they canceled the entire product. It’s a good time to stop working, especially since we were all laid off. We weren’t going to, I want to finish this. You’re not paying me. I’m done.

Sam Falco: [18:34] So does that makes sense that concept of the balancing stability and flexibility?

Dan Neumann: [18:39]
I hope so. I mean, for me it does. Right. ,, you know, we’ve, we’ve got a Sprint. We want the team we’re asking Scrum teams to deliver an increment it’s horribly unfair to then mess around with what they’re doing in that increment, with that Sprint goal. And you were talking about Scrum Sprints being mini projects basically.

Sam Falco: [19:02] Yeah. Before I get into that, let me just say if the concept I just discussed isn’t as clear as you’d like it to be. You can always email us at podcast@agilethought.com and we’d love to get listener questions and run with them. So if you have a question based on that, let us know. We hear in agile all the time. Oh, we don’t do projects and that’s not entirely true. The idea is that we want a product oriented mindset where we are creating a product and maintaining it and sustaining it and building on it as we go. But projects, aren’t an anathema to agile and especially to Scrum. In fact, the Scrum guide says in your I’m quoting, each Sprint may be considered a short project. So we think of our definition of project where it is and has a specific duration. And it has a desired end point. Well, that’s, that’s a Sprint. Ken Schweiber. We have a quote here from him. A Scrum project is only one Sprint long, a release of software may be the s, of multiple increments and to previously developed software, if any, or there may be multiple releases of software within a Sprint.

Dan Neumann: [20:15] Decoupling releasing from the Sprint from projects, right there cases.

Sam Falco: [20:21] Right. And what we talk about in the professional Scrum master class is that we’re just looking at a shorter horizon. Often projects in the past were year and a half, two years or longer. We can talk about different levels of project essentially. We can talk about, oh, we have a project to deliver something in three years, but our project is our one month Sprint or two week Sprint or whatever it is, ,, that, and then you don’t have to worry about the idea of a project fails.

Dan Neumann: [20:54] The variability, the chances for things to be variable and go wrong, get reduced significantly as you bring that horizon. And what am I going to do this week? I can probably tell you, what am I going to do this year? Beats me, I don’t know.

Sam Falco: [21:08] Right. And that speaks to a couple more of the principles behind the manifesto that our highest priority is early and continuous delivery of valuable software that we want to deliver working software frequently, the exact phrases from a couple of weeks to a couple of months with preference to the shorter timescale. And that’s what we’re talking about here. Yeah. We want to build all a big thing, but right now we’re going to build a small thing and make sure we’re on the right path. And that’s what a Sprint gives us the ability to do.

Dan Neumann: [21:44] So we’ve talked about a bunch of different factors that might influence the Sprint duration. Let’s get down to brass tacks here. So let’s, uh, let’s start with the short ones shorter than a week. What do you think?

Sam Falco: [22:00]
,, bad idea, at least according to Ken Schwaber, I think it’s in software in 30 days in one of his books, he says that he believes that the pressures would be too great to do shorter than a week on a team. I actually suggested three-day Sprints to a group I was working with at one point because they had three week Sprints and they were not getting to done. And it was not because they were struggling with all of the things they had to do was they were taking on way too much work. They had no idea how to predict what they could do. And so they’ve been doing a lot of taking on too much and then rolling it. And I said, well, instead of extending your Sprint, what if we did in the next supposed three week Sprint, it was a scaled effort. What if we did 10, three day Sprints? And I thought they were going to murder me because they went right to that’s going to put an enormous amount of pressure on us. And I said, I agree. That was, the idea was, let’s just do one thing. And every three days we we’ve done one thing. They ultimately opted to do one week Sprints for the next three week program, Sprint level per Sprint, to see if they could bring it down. And that, that was very stressful, much more stressful than three weeks was, uh, but less than three days would, would have been.

Dan Neumann: [23:24] But it was very focused. And so there’s focus there. Uh, at some point you get short enough with the Sprint you’re essentially doing flow, not iterations. So, you know, there’s some things there, so let’s b,p out to, yeah. What about a week?

Sam Falco: [23:39] Yeah. A week is not common in my experience. Like I said, this team did it, but they only did it for three within the Sprint that the, that the scale program was delivering. It’s very stressful. I use Scrum personally to manage my fiction writing and I use one week Sprints, but I’m just one dude. So it’s a lot less stressful. ,, but for most teams, I think it would be too too much.

Dan Neumann: [24:05]
Yep. Sorry. I stomped on you. I’ve done one week Sprints in the scenario was product owner in New York city. Very complicated business domain. Hard to explain, even to me in Indiana native English speaker, our team was in China, a very talented folks, very young, some language barriers, new to the domain. We couldn’t plan a two week Sprint to save our life. So we limited work in process. We focused in on this. We only need this in the Sprint. Okay. And we, uh, we had some success with that. So that was the scenario under which I have used one week Sprints.

Sam Falco: [24:43] Right. And part of the value there is if there’s a high risk of failure, because in this case, in your case, language barriers and all that remain actually there, right? Yeah.

Dan Neumann: [24:54]
There’s no risk of failure. It was self-evident. Right.

Sam Falco: [24:57] Right. But instead of waiting for a month or two weeks or three weeks or whatever, it would be one week. Okay. And then you don’t run the risk of saying, well, we’re failing. So we’re going to keep scrapping the Sprint and we never get anywhere instead. Okay. Well, let’s just finish this one week pile of, of, of pain. ,, try not to be bleeped.

Dan Neumann: [25:20]
Uh, well, let’s, let’s just draw line based on this math formula. Cool. Right. Let’s you know, so let’s move out. So, uh, some scenarios for a one week, two weeks Sprint, uh, I believe state of agile would say that’s the most common one.

Sam Falco: [25:35] I’ve heard that. I don’t know that it is it’s in my experience, it’s been the most common. That was where we started. When I first started with Scrum, the, the organization you’re doing two week Sprints. And that was actually a good length for us, but it’s not a good length for everyone in all domains. Once again, we have to take into consideration our definition of done. What is all of the stuff that needs to be done if you have an enormous amount of testing beyond what I’m just going to say beyond, but I don’t know where the cutoff is. It’s kind of relatively, just a lot of testing, ,, in order to this, well, maybe you can’t get everything done inside of two weeks in the need to go longer while I will strenuously object to is when I hear people say that that’s the right length. The two weeks is the right length. ,, Horsefeathers two weeks is an appropriate length for many organizations and many domains, but it is not the right length.

Dan Neumann: [26:32]
Yeah. And what I love about the two weeks print, you have a lot of opportunities to inspect and adapt. So things like holy cow, we have to test a of this. It takes a long time. Well, the easy solution as well, we’ll just do a testing and a separate Sprint. The second easiest solution is, well, let’s just do a code freeze half to two thirds of the way through the Sprint. Right. Or right. The answer is, huh? How can we get validation faster? So that h,ans who are expensive, don’t have to do this manually, every Sprint, right? You go solve that problem. You don’t work around the impediment.

Sam Falco: [27:15] I loved that. Yeah. That where the testing had gotten, we hit, we didn’t have automated testing and the testing was getting longer and longer. And finally, someone higher up the chain says to me, why is testing to it used to only take you X n,ber of days? I said, yeah, last year, but we’ve added all this new functionality. We have to regression test everything. Will you now give me a budget for automated testing and suddenly, oh yes. And then we had a separate Scrum team that was involved with building a test automation platform, because I don’t know why they didn’t want to buy one. I forget why there was a reason build one that worked for us and then suddenly that perfect. Oh, now we can do more stuff inside of a two week Sprint and, and deliver more value.

Dan Neumann: [27:58]
I love it. So keep, let’s keep walking up the ladder towards the month, uh, three weeks.

Sam Falco: [28:04]
Yeah. I like three weeks Sprints because for the exact reason that a lot of businesses don’t, because three weeks doesn’t align with a 52 week calendar. You can’t fit. You have, if you’re doing quarterly that’s you got an extra week there. Where does that go? Uh, and I like that because it forces businesses to think a little differently about how they’re going to release. We’re hopefully we’re going to make it possible for you to release more often than that and think a little outside the box. But I understand that I’m bucking 150 closing on 200 years of industrial thinking.

Dan Neumann: [28:45]
Annual budgeting, quarterly for whatever. Yeah the tyranny of the calendar is amazing. Just the way it permeates everything. So I love that you’re tilting against that windmill, Sam.

Sam Falco: [28:57] I, I worked with, well, I didn’t work directly with, uh, I was acquainted with a developer who is now a, a, a PST in the, in the community, PSD community, teaching the developer class. And he loved three weeks Sprints. He would always start with, we’re going to start with three weeks Sprints for exactly that reason. He liked to shake things up. And he told me about a one day and I said, oh man, I liked that. And then I was in a program where they did that and it was the business hated it, but what they loved was yeah. But every Sprint you’re getting stuff. So yeah, it’s gonna, it’s going to be weird because you’re going to plan your release strategy for the quarter around four Sprints and have an extra week. So what, so in the third quarter, you’re going to get an extra Sprints worth of stuff, hooray, or, you know, whatever. So I liked that, but, uh, I see the drawbacks. I see the, I see the arg,ent to be made for no, if we’re not going to do three weeks, we might as well just do a month.

Dan Neumann: [30:00] So what about that month for me, the bigger, the time box gets the harder it is to know how much fits, you know, harder to pick up what’s right. Is it too the Goldilocks too big, too small, just right.

Sam Falco: [30:13]
I think that, and I’ve had two teams in my history that used one month Sprints after just like any other Sprint length after about three Sprints, the team starts to figure it out. If they’re left alone, the problem comes with businesses, see that month and they go, oh, well, I can just put something else in there because we’ve got plenty of time and teams don’t push back or can’t push back for whatever reason. And then the one month Sprint gets this bad rap. So I would suggest to businesses to really think about, do you need a delivery faster than a month of an entire Sprint goal? Can you take incremental deliveries within that Sprint? Because remember we can still do that, but let us work towards a Sprint goal in a month. I’ve been thinking about this a lot lately, and I’m starting to wonder if one month is the right length for, for many more Sprints, for many more organizations than are currently using it. Again, there’s no right length for a Sprint other than no longer than a month. But wondering if organizations would do well to give their teams a little more space to innovate, to build quality in because what’s often happening is there’s pressure to compress the Sprint length. And so what happens under that pressure to deliver faster, faster, faster is teams. Whether they do it consciously or not start cutting quality. And we never want to do that in Scrum.

Dan Neumann: [31:57] Right? I think the challenge would be to address some of the underlying challenges that make waterfall projects a bad idea. One month Sprints look like a waterfall are going to be a bad one month Sprints where everything’s getting done in the last week done handed off today. The way in the last week is, is a recipe for disaster. So if those fundamental drawbacks to, to a long gated stage type of approach are handled.

Sam Falco: [32:30] So we have to talk to the business about what, what risk is there? What real risk is there? Can we quantify it? And if we can, let’s, let’s do that and maybe do some experiments. ,, can you commit to leaving the team alone? And another thing I have, I have coached organization at times. Well, let’s go with the shorter Sprint because the business is just not going to stop throwing things at you, but at the same time, really need to coach the business to stop throwing things at the team. So there was a dual effort going on there. I think one of the things I coach is to pick the shortest Sprint length possible for you to start with. Then we can always relax that a little later. If we, if, if that really needs to, because teams often feel like they can’t do it that short, and I want to show them yes, they can. However, as I said, I’m starting to rethink that. I’m starting to think maybe what we really should be doing is start with a one month Sprint. And if the business really can’t accept that risk, then we look at well, what can we do? But know that your increments are going to be tinier. What you’re going to get is going to be small. You’re not going to get twice the work in half the time. You’re not going to get what you’re expecting from a Sprint. If you shrink the Sprint length.

Dan Neumann: [33:52]
Cool. And so people interested in running experiments can go back and listen to the experimental mindset podcast episode with Adam jewelry from, uh, from some time ago. But, uh, boy, Google will find it for you. Well, let’s put a bow on this then. We explored Sprint durations anywhere from less than a week up to the month. And a couple takeaways then sound like, you know, pick, pick one is what I heard you describing. Right?

Sam Falco: [34:19] Pick up, pick a Sprint length that will feel like everyone wins businesses. Businesses say okay. We were going to get something in three weeks. Let’s say, and teams are like, yeah, that gives us the space. We feel comfortable with that, but there’s a negotiation. There’s always the trade-off. So be aware, both sides need to have empathy for one another business needs to talk to their Scrum team, not just, uh, use the product owner as a proxy and just demand stuff. Scrum teams to talk to their stakeholders, not just use the product owner as a proxy, so they don’t have to go talk to people.

Dan Neumann: [34:57] And then I’m ass,ing we should stick with this for a while.

Sam Falco: [35:00] Yes. There’s nothing wrong with changing your Sprint length. If it really isn’t working. But the flaw I see happen is the teams do one or two Sprints and go, that’s not working, so we’re going to change it. Well, whoa, whoa. Let’s, let’s live with that for a little bit so that we can, as you said earlier, let’s look at what the problem really is. Why does this feel like too short or too long, a Sprint length. Often it’s too short. Why? While the testing is just impossible to get done. Oh, well what could we do about that? So I usually say, because we often coach this, that it takes teams about three Sprints to, to start jelling and start getting things together. So at least three Sprints with the chosen duration and then try to solve the problems that are causing you to, uh, to trip before you say, well, let’s just, let’s just make this Sprint length longer.

Dan Neumann: [35:50] Perfect. Perfect. Well, thank you Sam, for taking time to explore the options for Sprint duration and solidly sit on the fence of it depends. This is a very, very solid consultant.

Sam Falco: [36:00] Very committed to that.

Dan Neumann: [36:04] Because, well, it actually does depend. So thank you again for doing that. I am guessing that there’s something on your continuous learning journey because you are not only a writer, but you are a, an avid reader. So what’s on continuous learning journey. Right now.

Sam Falco: [36:20] I have just started reading out of the crisis by W Edwards Deming who was an early pioneer in quality management. He went to Japan after world war II and helped them rebuild their industry and had a lot of differences with the way management worked. Uh, he was also, he, when he came back to the United States, worked with Ford to increase their quality. And this book was published in 1982. And it’s often referred to this as 14 points. Here are 14 things that you need. I’m not very far into it, but I’ve always been a fan of Deming just because my dad was a fan of Deming quality management. He really, he had read, I don’t know if you read this book, but he read a lot of Deming stuff when he was in, uh, engineering management in the hotel industry and used a lot of those principles. But one of the things that I took note of right away is in Stephen Denning with N’s as a Nancy in his book, age of agile, he spends quite a bit of time at the end, deconstructing the idea that corporations only exist to create shareholder value and talks about how pernicious this attitude is. And it begins around 1980s when Deming with M’s is writing that. And I have a quote here that, uh, I just love performance of management should be measured by potential to stay in business, to protect investment, to ensure future dividends and jobs through improvement of product and service for the future, not by the quarterly dividend. So here is this Titan of quality saying this and, uh, businesses. No, we’re just going to chase shareholder dividends and that causes all sorts of problems. So read both the age of agile by Steven Denning. And I’m now reading of course, out of the crisis by W Edwards Deming, just to see what pre agile lessons I can learn.

Dan Neumann: [38:25]
That’s awesome. And we’ll be sure to put both of those into the show notes so people can get the Deming and the Denning and not confuse the two of them because I likely would. And, ,, I think we’ve got on our backlog. Uh, we’ll be talking about Taylorism probably in about a month. We’ll, there’ll be an episode on that. And I think if I remember right, Denning is going to come in. Yes.

Sam Falco: [38:51] Both Deming and Denning come in, Danny. I think would’ve poked Taylor in the eyes, but I’m not sure that.

Dan Neumann: [38:59]
It will be fun. Well, we could, uh, we’ll have to see if MTV ever did a celebrity death match of Taylor versus Deming. Yeah, I probably, uh, it’s probably been 30 years. I’m not even sure that’s still a thing. So apologies to anybody younger than 30. Who’s like, what’s the hell celebrity death match? Does it match Google it it’s probably still out there. Well, Sam, thank you very much. And we will talk again soon. Chao.

Outro: [39:30] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.

Stay Up-To-Date