Sprint Backlog

One of the three artifacts in the Scrum 353 is the sprint backlog. Now, the Sprint backlog represents the short range commitment that the teams are going to execute against in the coming Sprint. It's created at Sprint Planning and really is comprised of three different pieces. Let's take a look at those. First, we have the Sprint goal. The sort of why, why are we working, working on these things? It's where the Sprint goal is. Second, we have the what, what are we going to work on? As represented by the product backlog, items that the team has committed to during Sprint planning. And finally, we have the. How, how will we get this done? This is the Sprint backlog represents the actionable plan by which over the next 10 days, the teams will, will execute on their commitments. Now, the Sprint backlog is created from the product backlog. Now, I want to, I want to pause here a minute, so just hang with me because this, this can kind of get confusing. So I talked about the product backlog. It's volatile. The product owner is moving things around and adjusting and reprioritizing. It is not committed work. Remember I said the product backlog is a list of the things we might do. Okay, The Sprint backlog, however, that's committed and that shouldn't change. When we come out of Sprint Planning and we have the Sprint backlog, we're stacking hands and we're saying, no kidding, like this is what we're gonna do. We've got the Sprint goal and we're gonna do everything in our power to meet that. And the Scrum master and product owner, they're gonna commit to protecting the team from any changes being made to that Sprint backlog. So it does represent commitment. So let's give you an example. Let's say the product backlog. We have a series of stories, story, you know, 1, 2, 3, 4, 5, 6, 7 and 8 in the product backlog. And during Sprint planning, we've gone through that information and we've pulled in story one, two, three and eight. Well, you might be saying to yourself, well, why would we commit to a lower priority item? Well, there could be a number of reasons. One is items one, two and three. We've got clarity on. But item four, it's just like it's too big. Five is too much unknown. We don't know. But look at number eight. I know it's a lower priority item, but we actually have some capacity. Can we work on that one? Most product owners will accept that and say, yeah, pull in that, that priority number eight. Now Once it gets pushed into the sprint level backlog, that becomes committed work and the product backlog, then priority is readjusted there. So just because the product backlog is in priority order doesn't necessarily mean you're going to do them step by step in that fashion. Remember the Agile Manifesto principle? Welcome changing requirements even late in development. Agile processes harness change for the customer's competitive advantage. That principle is absolutely true in the product level backlog. We welcome change even late in the process. And so that backlog is changing. The sprint backlog, however, is committed and shouldn't change now. You guys, this is why I highly recommend a 2 week sprint. If you start getting into 4 week sprints and you're asking your product owner to commit to a bigger batch, like four weeks, that's when you start to wrestle with, I thought you guys said you were agile and you could welcome changing requirements. True. That's why I only, I only want to lock in for 10 days. So shrink that time box, shrink that sprint backlog. You'll have, you'll be much more effective in that. Remember that we're committing to the goal because clarity may need to come about and new stories could be written or stories could be sort of not executed to meet the sprint goal. So our sprint backlog, the commitment out of that is the sprint goal. So something to keep in mind there. So Sprint backlog, another one of our artifacts.