Introduction: Music, Rhythm, and Scrum Share a Common Beat
I love music. Don't you love music? Some people don't. I love music. What I really like about music is the container that is within the rhythm that suggests the cadence of the music. And in that way, one person or many people can share that same piece of music. You play something now, that's something to do with Scrum. Let's talk about it.
Hi, my name is Lance Dacy. I am otherwise known as Big Agile. And a lot of times we will hear, and I hear a lot of noise out there on LinkedIn too, about Scrum and the rules of Scrum and the constraints of Scrum and all that good stuff and how that is not really agile. And I'm like, well, I spent a lot of time teaching Scrum, coaching Scrum and it is one of the most widely used Agile processes. So I wasn't going to go into all of that, but I do want to make sure that we pinpoint one of the really important and I think wonderful pieces of Scrum that a lot of people overlook.
Understanding Scrum's Time-Boxed Structure
And that is the cadence in Scrum. If you're not familiar, come on to one of our classes and we'll be able to show you that. But Scrum basically operates in these series of time boxed or fixed length iterative time boxes called sprints. And it's a bad name for it because it implies we're running as fast as we can, but we're not. But at any rate, you come up with a sprint link that is either 1, 2, 3, or four weeks, or typically the language will say one month or less.
And what we're trying to do is figure out how much work within that sprint we can deliver as a team, and then by the end of the sprint have something that's actually usable and deliverable. And Scrum is one of the very few agile processes that actually has that constraint. So if you practice a Kanban that is absent of a time box, right, you can artificially put a time box on it, but Scrum has a constraint that says your sprint can be no longer than a month, and by the end of that month you must have delivered a usable increment to be able to call it a success or not.
Now, if we didn't build that, of course we go back and figure out what happened and try to get better at it, and that's okay. But let's talk about the sprint and the cadence and the importance of that cadence just for a moment.
Stop Starting Work and Start Finishing Work
A lot of times I will work with teams and they'll try to take certain amount of work into this sprint, and then ultimately they won't be able to finish it all. And so one of the key concepts we try to teach Scrum teams is we want to stop starting work and start finishing work. Let that one sink in for a second. We want to stop starting work and start finishing work. We want to limit how much things are in flight at a time. And the whole concept of this cross-functional team swarming on work items, trying to get it done helps us try to focus on the idea of minimizing how many things we're working on at a time.
There is data out there that shows us the more things we try to work on and parallel, the longer everything will typically take. So what we try to teach our teams is limit how much you're working on at a given time. But that's really not what this lesson is all about.
The Power of Consistent Sprint Cadence
I want to talk about the cadence and the length of the sprint and how it should occur sequentially back to back. There should be no gaps in the sprint and they should be the same length all the time. So that way as we start gathering metrics, we can actually do better job predicting what we think we can deliver in a radically unpredictable environment. So there's a lot of things we can do to help us stabilize that as much as possible.
The Days of the Week Analogy
Now, the analogy I like to use for this is the days of the week. So let's just pretend here that we're going to put fixed length iterations on the days of the week. So in that case, our sprint would be 24 hours. I'd never recommend y'all do that, by the way, but just for the analogy sake, let's talk about it in that way. So Monday, Tuesday, Wednesday, Thursday, Friday, we have five sprints in a week. Each sprint lasts 24 hours long. Now, Monday sprint starts at midnight and it ends at 11:59 and 59 seconds. And there's nothing anybody can do about that. That's what a sprint is.
So let's pretend that I'm just a one man show here and I'm going to try to operate in a sprint. So I think on Monday that I can deliver, let's say maybe five things. I put five tasks on Monday. Now in Scrum, this would be something called your sprint backlog. Your sprint backlog represents not only the work that you're committing to delivering from the product backlog for that sprint, but it's also typically elaborated with a plan on how we're going to do it.
That'll be in another lesson. But for right now, let's just say I agreed to take in these five work items into my sprint, which is Monday.
What Happens When Work Isn't Finished
So Monday at midnight, we would start sprint planning in which I would decide to take in these five items all throughout Monday. I would start working to finish some of these items and let's say throughout all the days on Monday, I get task one done, task two, finally task four. So what happens here then is we start tracking that work, we pull it into the sprint, and then as we finish it, we take it off of the, it got moved to the done column. It's no longer outstanding. And that's typically what a product backlog is, is just a list of undone work.
But now I'm feverishly trying to get through item three and five on this list that I committed to delivering, but it's approaching midnight on Monday night. So it's 1158 or so on Monday evening. And a lot of teams would say, oh, well, let's extend Monday. So they would draw a line and say, we're going to move Monday into Tuesday a little bit and make it a little bit longer. I don't know if you've ever seen teams like that. They're like, oh, I just need one more day. So they'll add another day to the sprint, but that is not what we should do.
Why Sprint Length Cannot Be Changed
The sprint length is the sprint length, and you can't change it. The only way we can alter it is if the product owner terminates or cancels the sprint. But otherwise, the sprint is the sprint. The sprint really doesn't fail. The sprint really doesn't succeed. That's like saying Monday failed or Monday succeeded. It's like, no, no, the day in the sprint is going to happen. Regardless, what we're talking about is the work of a sprint.
So what I would like to highlight here is what do we do about these two items that are not done? So a lot of teams will try to extend the sprint. Other teams will pause the sprint, just say, just put pause on the sprint. We're going to keep working on it. But really what's going to happen is these items that I have that are undone are going to have to move into the next sprint.
Handling Incomplete Work and Building Predictability
Now, I'm not always saying that it's going to go into the very next sprint. The language we typically like to use is it's going to get pulled out of the product backlog or pulled out of the sprint and returned to the product backlog for reprioritization. And that might, if you've got 'em partially done and they're still important, they'll likely move on to the next sprint. So here we are with Tuesday.
Those might be the top two items that need to go into Tuesday, and then I'll add a few more. But as far as how much work I actually got completed on Monday, it was only three items. So in Scrum we have this concept called velocity, which is actually tracking the rate of done increments that have met our team's definition of done. And that really starts turning it into a good, predictable way to assess how or how long things are going to take, how much they're going to cost. We can start answering those questions a lot better.
Understanding Velocity in Scrum
So we got three items done on Monday, and then teams will go, well, we get partial credit for the stuff in flight. It's like, no, you only take credit for the work in the sprint that it got done in. So Monday gets three, and then Tuesday I got two that are partial. So I'll probably bring in some more work. And let's say I got eight things done on Tuesday. Then what you're going to do is start averaging your velocity. It'd be three plus the eight, which would be 11 divided by two, which would be roughly over five, would be our average velocity for that.
The Secret Sauce: Why Cadence Matters
So that's an important piece of Scrum that I think a lot of people overlook is that the cadence of the sprint is really important. It keeps everybody on the same page about how much work we can actually do helps us plan better, and the metrics that we gather from it help us to be more predictable for the long run.
The consistent rhythm of Scrum sprints creates a shared container - much like music - where teams can synchronize their efforts, build predictable delivery patterns, and continuously improve their performance. This cadence isn't just a constraint; it's the foundation that makes everything else in Scrum work effectively.
Ready to Master Scrum's Cadence?
If you would like to learn more about these concepts, we talk about this in our certified Scrum master workshop or even our uncertified team-based workshops. Understanding the true power of Scrum's cadence can transform how your team delivers value and builds predictability in an unpredictable world.
Ready to dive deeper into Scrum mastery?Explore Big Agile's comprehensive classes and workshops designed to help you and your team unlock the full potential of agile methodologies. From certified Scrum Master training to hands-on team workshops, we'll guide you through the practical application of these powerful concepts.