In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann will be focusing on the topic of getting to “done” within a Sprint.
Getting an increment to “done” is really challenging—even for Scrum Teams that have been working for a while. So, it is especially challenging for folks that are new to Scrum and Sprinting altogether. Even at the longest duration of a Sprint (which is one month), it can fly by incredibly fast! So if you’re used to really long delivery cycles with long requirements, think about how fast a two-week Sprint will go.
So how might we get to a “done” increment? Tune in to find out.
- What does it mean to get “done” in a Sprint?
- In the Scrum Guide, it says that the increment must be done and in usable condition
- The team ultimately decides what “done” is (but it does need to be in usable condition)
- What do we not want to do to get to “done?” What methods—though, often posed—simply do not work?
- Nailing the requirements up-front so they’re moving because it’s easier to hit a static target than a moving one
- Building within the Sprint and then testing within the next Sprint (which is a non-option because within each increment it should be in a usable condition)
- Build for seven days, do a code freeze and then test for three (which is ineffective because you end up with questions such as: “What did the developers do for the last third of the Sprint?” And, “What do the quality specialists do for the first two-thirds of the Sprint?” etc.)
- Implementing “Wagile” (Waterfall-Agile), where you nail the requirements and then iterate through the delivery of the requirements through the Sprint
- Extending the Sprint because the work isn’t done (this is the best time to stop and have a retrospective)
- Dan’s recommendations for new teams looking to get “done” every increment:
- As a Scrum Team, collaborate to break your product backlog items down into smaller pieces (small batches are going to move through the Sprint faster and a smaller product backlog item will get delivered more quickly than a large product backlog item (it’s far more valuable to have 9 things at 100% and 1 at 0% than to have 10 backlog items at 90%)
- Make sure that everyone on the team is really focused on quality
- Really maximize the amount of work not done; ruthlessly focus on meeting the acceptance criteria for your product backlog items and no more than that
- Pull your testing forward
- An activity that can be super valuable for Scrum Teams is to have a subset of the team (representing quality, development, and the Product Owner) to get together and define what the test cases are that will ultimately have to pass
- Look for tools to support the people and interactions—tools can really help your Scrum Team move forward rapidly (activities like paired programming and mobbing can help with this)
- Dan wants to hear from you!
- What ideas have you tried and seen work for getting code to “done” within a Sprint?
- What have been some things you’ve tried and haven’t worked?
- Would you be willing to start taking more notes throughout your day and then give yourself some time to reflect on those and identify your own areas of growth? And, if you do, what did you find out?
Mentioned in this Episode
- The Scrum Guide
- “Wagile” (Waterfall-Agile)
- Pair Programming
- Mob Programming
- Agile Coaches’ Corner Ep. 45: “The Benefits of Mob Programming with Chris Lucian”
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro: [00:03] Welcome to the 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:17] Welcome to Agile Coaches’ Corner. I’m your host, Dan Neumann and thanks for taking the time to download and listen today. The topic I’ll be exploring today with you is really focusing on getting to done within a Sprint. For folks that are practicing the Scrum Framework. What we’re looking to do is get an increment at the end of every Sprint and when you go out and look at the Scrum guide that says that the increment must be done and in usable condition. The team is going to be the one that owns that definition of done, so what exactly it means, but it does need to be in usable condition per the Scrum guide. Of course the decision to release that increment or not is up to the product owner and we’ll leave that aside for a topic for another day. Getting an increment to done is really challenging even for Scrum teams that have been working for awhile. And it’s extremely challenging for folks that are new to Scrum and Sprinting even at the longest duration of a Sprint, which is one month that time flies by incredibly fast. And so imagine if you’re used to really long delivery cycles with long requirements design test and then shipping processes. Think how fast a two week Sprint is going to go. I mean that’s crazy fast. So how might we get to a done increment? Well if you are of a predictive mindset, one of the approaches that might come to mind for you is, Hey, you know what we should do? We should nail the requirements up front so they’re not moving because it’s easier to hit a static target than a moving one. So before the Sprint starts, there might be a desire to nail the requirements and then you know, we might build within the Sprint and then test within the next Sprint. That’s often a scenario that’s posed to me when I’m starting to work at the brand new Scrum teams. Hey, let’s just nail the requirements, build one Sprint, test next Sprint. So as you think through that then and try and put that against the Framework of the Scrum guide that really says, Hey, we want a working done increment of software every Sprint. The notion that we can validate it later, test it in a separate Sprint becomes a non option.
Dan Neumann: [02:32] Okay, well what if we were to within a Sprint, let’s say it’s a 14 calendar day or 10 business day Sprint, what if we were to build for seven days, do a code freeze, and then test for three? That does give us potentially an increment that’s done because it’s been validated, but then you end up too with questions like what do the developers do for the last third of the Sprint? What do the quality specialists do for the first two thirds of the Sprint? And so pretty quickly that notion of simply kind of water falling, the two week Sprint falls apart. Of course there’s a little bit of a pejorative term called wagile or waterfall agile and that’s the desire to nail the requirements and then simply iterate through the delivery of those requirements in a Sprint. So would discourage you from taking a Wagile style approach. And the reason for that, not just because you know Dan doesn’t like it; if that type of predictive, non iterative delivery could be used well then what you really could do is simply use that predictive approach through the entire delivery process. You could gather all your requirements if they’re not going to change. You could do all your building if you know exactly what you need to do and then you could validate it later. That non iterative, or predictive approach is really only going to work when you have extreme agreement on the requirements and extreme certainty with the technology. And to be honest, most of the teams that I see experience a lot of uncertainty about the requirement side and they’re doing new things with the technology and so that type of waterfall approach isn’t going to be effective for them. And that’s what leads to moving towards agile into iterative approaches. And in this case specifically, we’re talking about the Scrum Framework.
Dan Neumann: [04:34] So we’ve ruled out a couple options. Um, we should rule out that we nailed the requirements early and to a degree where we’re not going to need to get any feedback during the Sprint. That’s an unrealistic goal for most teams. We don’t want to waterfall our time box for the Sprint because that ends up with a couple things. It delays the feedback cycle on what’s been built. So the developers or the development specialists aren’t going to get feedback from the quality specialists until late in the Sprint. And we have lots of moving parts. They have a lot of features being built for the first two thirds and then being validated for the last third if that’s, you know, the scenario where somebody wanted to break their work down.
Dan Neumann: [05:19] So you’ve got long feedback loops, you’ve eliminated the opportunity to really collaborate with your customer or your Product Owner in that. And so those are a couple of things we do not want to do. So what do we do? Is there hope for new teams going to an increment in Scrum? The place I would recommend they start is to really shrink the batch size and in Scrum what that would mean is creating small product backlog items. So as a Scrum team collaborate to break your product backlog items down into smaller pieces. Smaller batches are going to move through the Sprint faster. So a small product backlog item will get delivered more quickly than a large product backlog item and at the end of the Sprint, if something doesn’t get completely done and isn’t in the increment, at least you’ve got the majority of the backlog items. It’s far more valuable to have nine things at 100% in one at 0% than it is to have 10 product backlog items all at 90% complete. In the first scenario, you actually can start to get value out of the ones that are complete and in the last scenario you have no value for your entire increment because nothing’s gotten to done.
Dan Neumann: [06:42] So shrink your product backlog items by slicing them up. Think of slicing through layers of a cake. You want to have small product backlog items and because they’re small, some of those are going to get completed early in the Sprint. They’re quicker to build, they’re quicker to validate. Your Product Owner has fewer things to give feedback on at a time and so you’re going to really get that machine turning much faster within your Sprint. Effectively what you’ve done is you’ve shortened the feedback loop. You take a small piece of requirement, you build it. If you have questions, you ask the Product Owner, you engage with the test specialists and the test specialists are engaged with the developers to clarify what done looks like, what tests will need to pass and when there is a need to engage with each other as the other developers then show the other developers when you’ve really shrunk that feedback loop. So that’s probably the first thing and the most valuable and easiest place to start. Small PBIs delivered early with short feedback loops.
Dan Neumann: [07:52] The next thing I would do is make sure that everybody on the team is really focused on quality. Quality of the increment is not the domain of a subset of the Scrum team. It’s not the testers job to make sure that stuff works. It’s the Scrum team’s job to make sure the increment is delivering value and is working software. Once you have everybody focused on quality, another mindset shift is to really maximize the amount of work not done. Ruthlessly focus on meeting the acceptance criteria for your product backlog items and no more than that. We run the risk when we start thinking of future scenarios that aren’t in the PBIs that we are going to be building capabilities that aren’t needed. You’ve got more code to maintain, you’ve got more things to get feedback on and you just end up creating so much more than is really needed to deliver on the PBIs, so maximize the amount of work not done. And pull your testing forward. One activity that can be super valuable for Scrum teams. Before we start slinging code about a product backlog item, have a subset of the team, often at least somebody representing quality development and the Product Owner get together and define what the test cases are that are ultimately going to have to pass. You don’t have to build all the test cases and all the details, but this is where you’re starting to make sure that there’s alignment between the Product Owner, the dev specialists, the quality specialists, anybody else on the team who’s going to be delivering that increment. So you pull that test forward, you’re defining what the tests are, the development folks know exactly what they need to hit. The quality folks aren’t going to be surprised at what’s delivered later and together you’ve really got a lot more clarity and alignment. You can look for tools to support the people and interactions. Yes, there’s an agile value of people in ag interactions over processes and tools and at the same time tools can really help your Scrum team move forward rapidly. And in this case, I think of tools specifically that are going to be able to automate the unit tests that need to execute. Because when you have automated tests that are validating your software, you check your code in, you can have a build fired off, it can execute those tests and you get immediate feedback whether A, your code is working as you plan and B, did you unintentionally break somebody else’s code? And so doing that manually is economically unviable. It takes way too much time, it’s way too expensive and it’s simply not going to happen. So look for tools that can support your quality initiatives. When Scrum teams are starting out, there is often a tendency to take product backlog items and give them to particular team members. And so if you’re listening carefully, there’s all kinds of things wrong with that. A, we are giving things to people, which implies some kind of delegation by somebody in positional authority. So we definitely want to avoid that and encourage more self organization. And secondly, when you have team members who are working on quote their product backlog item, their story, it takes away the collective code ownership notion that can be super valuable for teams. When you have collective code ownership, you have multiple people who are able to, regardless of the area of the application go in and make improvements to it, introduce new features. Your Scrum teams become so much more effective than when you have very tight ownership by specific individuals of different areas. So look for ways to increase code ownership, make it more collective. You can do this through activities like pair programming where you have two people engaging on the development of code with one computer. You could look for things like mobbing where you have a whole team who is collaborating on delivery of a feature. And I think when we talk about mobbing and you’re having a whole team focused on one item, that raises a lot of concerns about how might that work. There’s a previous podcast that we’ve recorded on mobbing. I’d encourage you to go back and listen to that for a bit of a deep dive on mobbing.
Dan Neumann: [12:39] Some of the benefits that get created from either pairing and or mobbing are really getting focus. One of the Scrum values is focus and when you have a couple of people working together, that ought increased focus on that delivery of the goal. It also creates more accountability. If you think when you go into a movie theater, you typically buy your ticket from somebody and you walk a few feet and you hand that ticket to somebody else. It’s because that creates a system of accountability. You can’t have somebody taking money and letting people in. You need two people to at least, uh, work to break that system. And I think that’s a little bit analogous to what we have with pairing. If the team has a definition of done, then you need two people to collaborate on making a conscious decision not to meet that definition. If there are certain Frameworks and patterns, especially new ones, now you need two people to decide that they’re not going to follow that process, or more positively, you have a partner in accountability who is saying, Hey, remember we’re supposed to do this using a particular pattern, or, gosh, this code’s getting ugly. Let’s refactor it instead of just holding our nose and checking it in. And so you’ve got increased focus, you’ve got increased accountability and the code benefits from having the increased wisdom of two people collaborating on the code. You get the best of both people going in instead of the both the best and the worst of an individual contributor.
Dan Neumann: [14:25] So those are just, uh, you know, maybe a handful of ideas on how to really work towards getting an increment done within a Sprint. A couple things to avoid would be don’t extend the Sprint because the work isn’t done when the work isn’t done and you’re realizing that your assumptions are maybe invalid, that’s the best time to stop. And a retrospective, which is at the end of a Sprint. So that is kind of the why for not extending the Sprint. I’d also be curious to hear what ideas you’ve tried and seen work for getting coded done within a Sprint. Or maybe some things even that you’ve tried and learned a don’t work. There’s a lot of learning in failures of things that didn’t come out the way you wanted them to.
Dan Neumann: [15:19] As for my reading journey this week, it’s not a traditional book reading or blog or anything along those lines. I’ve spent the last couple of weeks and I tend to do this, especially when I’m working with new teams, new engagements, doing assessment type work. I end up writing down a lot of observations as I’m engaging with people, either things that I heard, things that I’ve noticed, thoughts that I’ve had or questions that came to mind and I end up collecting those in a notebook and then periodically I’ll go back and I’ll look at my notes. I’ll look at photographs of flip charts and really start to look for patterns, new areas for me to explore, new ideas to share with those folks or potentially topics that emerge for this podcast. And it’s a great source of personal continuous improvement. So I have a challenge for you. Would you be willing to start taking more notes throughout your day and then identify areas of time to reflect on those either at the end of the week or perhaps when you have that urge to hop out to social media and you know, do something that is potentially mind numbing in some cases and do some reflection instead. Look for your own personal areas of growth. So I would love to hear if people have taken on that challenge and how it works for you. And then until next time, thanks for listening.
Outro: [16:47] 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 host and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode, and other episodes at agilethought.com/podcast.