In today’s episode of the Agile Coaches’ Corner Podcast, host Dan Neumann is joined by AgileThought colleague and return guest, Sam Falco. Sam is an agile coach and Certified Scrum Professional with an extensive background leading agile development teams. Today they’re highlighting exactly what it means to be ‘done in Scrum,’ why you should care about the definition of ‘done,’ how to go about shaping your team’s definition of ‘done,’ how to reach ‘done,’ and what you can do as a new Scrum team to overcome the hurdle of what ‘done’ is.
What does it mean to be done in Scrum? This is something that gets overlooked frequently. The Scrum guide says that the heart of Scrum is a Sprint—a timebox of one month or less—during which a done, useable, and potentially releasable product increment is created. So, for something to be done means it’s either in production or it’s ready to go to production without any further work. With new Scrum teams, this can be a major hurdle. It can seem like too much to ask.
- What does it mean to be done in Scrum?
- According to the Scrum guide, it means: during a Sprint, a useable and potentially releasable product increment is created (meaning it is either in production or ready to go to production without any further work)
- This definition of ‘done’ applies to the increment you’re creating each Sprint
- Everything has to be working and working together
- What can you do as a new Scrum team to overcome the hurdle of what ‘done’ is?
- Make sure your items are broken down small enough
- Make sure an increment is doable
- Remember that it’s better to deliver a small piece of value than a bunch of stories or backlog items that are not ready
- How to reach ‘done’:
- Work together toward a common increment
- Build a strong enough sprint goal that is aimed at creating a solid product increment
- Do integration testing
- “If it hurts to release, do it more often”
- Consider: what can you do to automate it and make it easier to release?
- If, as a team, you feel your Sprint is too short, consider the possibility that you’re perhaps trying to do too much
- Identify underdone work in the increment
- Use the Retrospective to frequently inspect your team’s definition of ‘done’
- Sam’s tips for how to go about shaping your Scrum team’s definition of ‘done’:
- The team should create it with the product owner
- Brainstorm as a team by considering the question: what does it mean to get work into production?
- Align with your company’s developmental standards if they exist
- There has to be a common definition that everyone agrees to and adheres to
- Why should someone care about the definition of ‘done’?
- Builds trust between business and IT
- Helps the team manage batch sizes by helping them to determine what they can do in a Sprint
- Helps the Scrum team be clear to the business about what they’re going to receive
- Helps you minimize technical debt
- Continual attention to technical excellence enhances agility
- Key takeaways around the concept of ‘done’:
- Start with what you know you need to do to get to ‘done’
- Don’t obsess about having the perfect definition of ‘done’ (especially if you’re a beginning team)
- Make sure that you have useful guidelines that will help you communicate what is ‘done’
- Remember that this can eliminate the cost of technical debt and make your organization more nimble
Mentioned in this Episode
- The Nexus Scaling Framework
- Agile Coaches’ Corner Ep. 33: “Nimble Facilitation with Rebecca Sutherns, PhD”
- Nimble: A Coaching Guide for Responsive Facilitation, by Rebecca Sutherns
- Definition of Done Example
Sam Falco’s Book Pick:
Intro: [00:01] 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 this episode of the Agile Coaches’ Corner. I’m your host, Dan Neumann, and today I’m going to be exploring what it means to be done in Scrum with my colleague and Professional Scrum Trainer, Sam Falco.
Sam Falco: [00:29] Thanks for having me again, Dan.
Dan Neumann: [00:32] Glad to have you and as a reminder to folks, the opinions that are going on here are yours and mine and not those of AgileThought or other folks or other organizations. So we are duly disclaimed as we explore done in Scrum.
Sam Falco: [00:45] Yeah, I thought it would be a good topic since we’ve done a few deep dives on topics in Scrum recently to talk about something that gets overlooked frequently, what does it mean to be ‘done’? The Scrum guide says that the heart of Scrum is a sprint, a timebox of one month or less during which a done usable and potentially releasable product increment is created. And so what we’re meaning here is that the whole point of Scrum is done for something to be done. We mean it’s either in production or it’s ready to go to production without any further work.
Dan Neumann: [01:17] And especially with new Scrum teams, that’s a really high hurdle for them. And I think it’s um, if you are an ongoing Scrum team, maybe where you’ve been going for a while and now we’re being asked to coach that team. It’s, it’s and even bigger hurdle cause they’ve got a bunch of legacy work there.
Sam Falco: [01:36] It is. Um, for beginning Scrum teams it often seems like it’s just too much to ask. Part of what you can do to help that is make sure that your items are broken down small enough and your increment is not overwhelmingly huge. Keep your eye on, it’s better to deliver a small piece of value that is solid than a whole bunch of stories or product backlog items or what have you that are not quite solid and aren’t ready to be accepted by any sort of stakeholder or customer.
Dan Neumann: [02:17] You were a talking as we were prepping. You were talking about a Thanksgiving dinner and analogy.
Sam Falco: [02:22] Right, so you can have all of your stuff in the oven and call people to dinner because it’s ready and oh, it will be ready in 45 minutes. We just wanted to get you up to the table. You’re going to have some angry guests. Done means for Thanksgiving dinner, done means it’s out of the oven, it’s ready to go to the table if it’s not already on the table.
Dan Neumann: [02:42] And one of the challenges I think for folks to wrap their mind around is the feature complete versus an individual product backlog item meeting definition of done. And I want to piggyback on your Thanksgiving analogy. So definition of done for the Turkey maybe is or that it’s not going to cause people food poisoning.
Sam Falco: [03:03] Um, well that’s an important definition.
Dan Neumann: [03:06] And that would apply to all of the things that you’re going to put on the table. I would hope.
Sam Falco: [03:10] And that’s an important distinction to make because definition of done applies to the increment that you’re creating each sprint, not merely each individual product backlog item. Everything has to be working and everything has to be working together integrated into one product increment.
Dan Neumann: [03:28] So thinking of definition of done for an increment, uh, we both travel a fair amount. So let’s talk about a sprint goal in which our hypothesis is we want to be able to purchase a one way ticket. So in order to do that, we might have a product backlog item to search for a flight, to actually pay for that flight and to be able to then select a seat so you’re not stuck in the middle seats in the back randomly.
Sam Falco: [03:52] Right. Okay.
Dan Neumann: [03:53] So we’ve got the three product backlog items and the definition of done for that increment. Then maybe you can expand on how those things fit together versus being done for each PBI.
Sam Falco: [04:01] Sure. So we might have acceptance criteria for each. PBI well certainly, should have acceptance criteria for each product backlog item and maybe they all work and we can demonstrate them. But in production, you book your flights, you pick your seat, you pay and the seat doesn’t get recorded. Well, it’s not done because it’s not all working together. And I see this frequently with teams where each, each product backlog item looks beautiful when you demonstrate it, but it doesn’t, they don’t float together.
Dan Neumann: [04:36] Yeah. I think that example would be helpful and when they don’t work together, it affects that transparency. We’re trying to build and build trust with the stakeholders because they see you, okay, I can search, I can pay, I can take money as a customer or as a company releasing this I want to be able to take money for the flight I’m selling and people get their seat and if they go, great, let’s release it and then the team goes, oh well…
Sam Falco: [04:58] Right, and this, going back to what we talked about earlier with beginning Scrum teams, this is often what I’ll see with their first definition of done is something to the effect of all acceptance criteria pass. That’s their definition of done, but then they fail to recognize that there’s, there’s more to it than that, that they have to get together all of those pieces to work towards a common increment and sometimes the symptom there, that’s the symptom and their root cause is actually not a strong enough sprint goal that identifies everything but that also it all ties in together, right? You have to have a good sprint goal that is aimed at creating a solid product increment and that increment is not just what you produced this sprint, it’s the sum total of everything you’ve produced from previous sprint to previous sprint to the current sprint, so there’s a lot of integration testing that has to be part of your definition of done perhaps.
Dan Neumann: [05:58] And these are the types of things I think some Scrum teams kind of forget about it, right? They get, like you said, they get too focused in on what are the acceptance criteria and have we met them and they’re not thinking holistically about the product increment or a meaningful sprint goal or how do we automate the testing so that we can actually do all the integration testing and make sure the increment works together without doing it manually. Because when you do it manually, it doesn’t get done.
Sam Falco: [06:24] Right because over time the amount of testing you have to do grows and grows and it becomes really hard for testing to be complete within a sprint. Um, early in my career when I was s QA team lead that came up very quickly where they would say, why is it taking you so long to test? I’m like, well look at all the things I have to test to make sure that this thing is ready to release or potentially shippable. Well, is there anything you can skip? Well, no, not if you want to be absolutely certain that what you are releasing is not going to blow up. And, um, we had to build a whole automated test system. As a result of that, we realized that this was, this was necessary. We had waited too long, so it was really painful. So I coached beginning Scrum teams to start thinking about that early. And again, that’s part of that definition of done.
Dan Neumann: [07:15] Yeah, it’s hard to bolt it on afterwards. You know, you’re making software decisions, you’re building more features. So more and more code every sprint if you aren’t keeping the automation and the validation up to date with it. Yeah, the economics just don’t work. You can’t manually test at all.
Sam Falco: [07:32] Right. And the Scrum guide does address that. It talks about the fact that this definition of done also helps guide the development team in knowing what they can pull into a sprint. How many product backlog items can they select? It’s not just a matter of, oh, we have a velocity of 35 and here’s 35 points worth of story. Well, we’re going to have to automate these tests or we haven’t automated a bunch of tests, so it’s going to slow us down some. The purpose of each sprint delivering that done increment. Um, it has to adhere to the team’s definition of done, so that tells them what they can do.
Dan Neumann: [08:08] Let’s touch on getting that increment as far as possible down the pipeline, a lot of teams, they have Dev environments, QA environments, maybe production or performance. Obviously production, maybe performance testing, staging, whatever those environments are. Okay. How far down that pipeline would you advocate for teams to go?
Sam Falco: [08:30] As I said, either in production or ready to go to production without any further work. So if it’s just in the QA environment, is it thoroughly tested? Probably not. If it’s in staging, maybe if it’s just a matter of script moving stuff to production and you have to wait for some business reason, that can be acceptable. Again, if we understand that this is, this is ready to go. So to go back to our Thanksgiving analogy, you might have a buffet where all of the dishes are waiting until everything’s ready and then move them onto the table or you’re going to have a buffet line. So that’s another way of looking at it as there’s your staging environment. But that stuff’s done. It’s cooked, it’s, it’s not going to kill anyone.
Dan Neumann: [09:16] A lot of teams, uh, we talked about the effort to manually test. A lot of teams are also starting with manual deployments. And one of the phrases that stuck with me, and I wish I knew from where I heard at first, it’s if it hurts, do it more often. So if, if it hurts to release, do that more often. Oh, it takes too long. Great. What can you do to automate it? How can you script or what can you do to make it easier and easier to release as opposed to it hurts to release so we do it instead of every month. We do it every quarter or we do it every six months. Oh God, we really can’t release because we don’t do it often enough and we in production. And so just making it easier and easier to do that.
Sam Falco: [09:56] Yeah. And another factor that can come in where that can be another factor. You’ll hear teams say, oh, we want to, we want to go to longer sprints because we can’t get everything done. Oh, well maybe the problem isn’t that your sprint is too short. Maybe the problem is that you’re trying to do too much or that you’ve got a lot of hidden work that isn’t covered in your definition of done, that you haven’t, you know, that you need to think about.
Dan Neumann: [10:22] Yeah, longer sprints to me is often an indicator of something else being a problem. The stories are too big. The engineering practices aren’t up to date. Uh, there’s too much technical debt, we don’t have automation. We want to do mini waterfalls.
Sam Falco: [10:39] Yeah. But as a Scrum team matures, the definition of done is going to expand to include more stringent criteria for higher quality. So that’s another factor that’s going to come in and you’re going to identify things that you didn’t think of before that’s gonna identify undone work in the increment. Oh, hey, we need to go back and increase our quality in some way. But it will also mean a little more work to get each product backlog item integrated into that increment. And if you don’t have good engineering practices, automation and whatnot, that will slow a team down more than than it should.
Dan Neumann: [11:20] Yeah. I think you touched on the evolving definition of done too. We’re going to start with something, you know, maybe it’s really simple as we, we can get going, especially for teams who will, maybe the organization that they’re in doesn’t have any history of automation. They don’t have any history of DevOps. They don’t have these organizational things to support moving quickly. So maybe they start with a simpler definition of done and continue to expand that over time.
Sam Falco: [11:43] Right. That’s one way to to go. So the beginning team we touched on earlier might not understand, so they’ll, they’ll create a definition of done that is not sufficient. It will become quickly apparent as stakeholders give feedback and so the team can use the retrospective and should use the retrospective to frequently inspect that definition of done. Is this good enough? Can we do better? Even before someone starts asking you for better, can we do better? Can we deploy more often? Can we increase our test coverage? That sort of thing.
Dan Neumann: [12:17] Yeah. And I might even, yes. Yeah. And maybe even just how can we just start with the assumption that we can indeed do better? We’re not a perfect team. We, you know, how can we make this faster, more reliable, more resilient? Yeah, I like that.
Sam Falco: [12:31] So an example of increasing the definition of done due to stakeholder feedback. Early in my career I was working on a product that was a Microsoft word add in and over time the load time for documents started to increase and we didn’t notice it because if you go from two seconds to three seconds, it’s not a big deal. If you go from three seconds to four, well after a while it was, it was taking half a minute for a document to load because of all the stuff we put in and, and a stakeholder said, we don’t want to wait this long. Actually, I was taking significantly longer than that. It was almost go get a cup of coffee after you’ve hit open. So part of our definition of done then became any document will open in less than, I think it was 10 seconds that, that we had to adhere to so we could get all of our product backlog items in the sprint done. Awesome. It all works. Oh it now takes 15 seconds for the documents load. We’re not done yet. We got to go figure out how we can shave that five seconds off. What have we done that’s introduced extra overhead.
Dan Neumann: [13:34] I love it. Yeah. So you’re, you’re taking a more holistic view beyond obviously the product backlog items. Looking at the increment, looking at the overall performance of the system, which in the waterfall days, performance was always one of the last things to happen. We build it and we performance test. You Go, oh, oh, you know, so now accelerating that risk earlier and earlier in the process. Fantastic. So how, how might folks go about getting started with their definition of done? What are some tips that you want to share first.
Sam Falco: [14:05] So, first of all, it’s something that the team should create. The Scrum team should create with the product owner or should have some input into this because they’re representing the stakeholders, obviously. I will often have a team brainstorm and just ask them what does it mean to get work into production and have them brainstorm all the things they need to do. We don’t need a comprehensive checklist. That’s not what we’re looking for here, but we do need some thoroughness and once they’ve brainstormed a bunch of things, I’ll sometimes separate things into what does it mean to be done with a product backlog item? What does it mean to be done to move into production? Just to get them thinking about those different levels of what they ultimately what I want to see is here’s what we need to do to get something into production. Start with what you can come up with. I mean just like a product is developed iteratively and incrementally. So is your definition of done. So identify what you think is done. Have your product owner be involved in that description and definition and then as you get feedback on the product from stakeholders, you will iterate and adapt your, your definition of done.
Dan Neumann: [15:34] So that definition of done example in the exploration we’ve had so far, it’s really a lot of, it’s been focused on a single team, a single Scrum team and obviously most Scrum teams are within bigger companies and so to be part of that company and aligned with some of those standards.
Sam Falco: [15:49] Right. If your company already has some developmental standards, then those developmental standards need to be part of your definition of done. If your company doesn’t have a commonly defined standard and your definition of done can go a long way towards establishing that. So maybe you have multiple products going on and you want to talk about what do all of our products want to have in common as far as quality. And then you get into the scaling situation where you have multiple teams working on a single single product. Now it comes, becomes more complicated just as everything becomes more complicated with scaling, so does your definition of done. So the Scrum guide says that if there are multiple Scrum teams working on the same product, then all of the development teams on all of the Scrum teams must mutually define the definition of done. So the bigger your organization gets, the harrier that gets. You have a couple of teams, it’s a little easier to get everybody in a room and say, what’s our definition of done going to be for this product? But if you’re talking larger than that, it, it becomes more problematic. And so there have to be some adjustments made there.
Dan Neumann: [16:55] And I think as organizations try to figure out what their organization’s standard is leaving room for that local context so that each team or each program or each product as in, because it may be hard to um, and may be inappropriate to have a big hammer that you hit all the teams with, but it’s um, maybe a common denominator across all of those.
Sam Falco: [17:17] Yeah, I mean all the teams have to agree on a minimum set of definitions of done. Some teams may have more stringent requirements. That’s fine. Now those more stringent requirements may get into the other team’s definition of done over time through retrospectives or just noticing, hey, that that team is doing this thing that is making life easier for them in the long run and we should do it too. So there has to be a common definition. Everybody has to adhere to at least that every team to adhere to release that. So in Nexus, the Nexus scaling framework, the definition of done is actually defined by the nexus integration team, which is a new role that nexus introduces to Scrum to help the teams integrate their work. The Nexus team doesn’t do the integration, it is responsible for making sure that it happens. And one of the ways it happens is it creates the definition of done that all of the Scrum teams must adhere to. And again, that’s a minimum standard. Each team can have more stringent requirements. So an example of that is I was in a scaled environment where the definition of done for the entire, uh, product did not include certain types of documentation within the, the code. One team said, no, we’re going to do this type of documentation and it’s not, uh, it’s not complete. Definition done means this stuff is documented so that other teams will have this information when they need to pick it up. And as I said before, that became, that part became part of the definition of done for the entire organization when other teams realized how easy it was to pick up the first team’s stuff and realized that they weren’t giving the same courtesy, so they’d be, that became part of the organization’s definition of done.
Dan Neumann: [19:06] Yeah. And it’s nice that the organization has latitude in there. So essentially different Scrum teams can experiment with different approaches to meeting that definition of done, to going beyond that definition of done. And then there’s a chance to learn from the experiments. So we’ve talked quite a bit about specifics of the definition of done. Let’s go back and touch on the why. Okay. So let’s see. We’ve got a good definition of done. Why should somebody care about the definition of done?
Sam Falco: [19:34] Right. So first I want to touch on the fact that this builds trust between business and IT. Part of the reason that agile has been so explosive is because it goes a long way to healing that dysfunction that had arisen in the old waterfall days of you demand too much. Well you don’t deliver what you promise. Agile is all about communication and small batch sizes and having a definition of done helps us manage our batch sizes by you know, helping us determine what we can do in a sprint and it helps us be clear to the business, here’s what you’re going to get when we say we’re done, it is ready to release. You can go to market with this now if the market has changed and made that valuable thing to do rather than, well, check with us before you do that because something might not be ready. So that’s one reason that it is valuable. Basically transparency. Okay. Another thing that it helps with, it helps you manage, uh, minimize technical debt, right? If you are always adhering to a definition of done that is increasingly stringent, you are making a lot less of, well we’ll just, we’ll do that later. Well that’s undone work and that can come back and bite you on the butt very quickly. So, um, working software is the primary measure of progress says the one of the principals in the agile manifesto behind the agile manifesto and working software means it works. It’s, it’s good. It’s solid.
Dan Neumann: [21:13] You touched on the other kind of a sister principal to that, technical excellence. Continuous attention to technical excellence enhances agility. You got your rigorous definition of done. You’ve got working software that’s, you’ve paid attention to the technical excellence.
Sam Falco: [21:28] Right. It enhances agility in that if the business needs to pivot, make a change. You don’t have to, oh well, but we’ve got to clean up a bunch of stuff first. So I used to do some woodworking and I don’t anymore because I’m not very good at it. Uh, well, one of the things was that one of the reasons I wasn’t very good at it was that I wouldn’t put away my tools and clean them up after projects. So essentially, here’s my technical debt lying around on my work bench and to go start a project, I’d have to go clean my work bench like I, I couldn’t just, hey, we need a shoe rack. I’m going to go make a shoe rack. It became an ordeal. Teams, software development teams can have the same principle happen if they’re leaving a lot behind, a lot of technical debt, well, we could start working on this new feature, but we left this hole in the architecture we’ve got to go plug. We knew about it, we just didn’t feel like doing it.
Dan Neumann: [22:21] I, I live that garage full of tools that need to be put away. So we’ll move on from there. We’ve talked about definition done related to Scrum teams and for those Kanban brothers out there I think this is one of those things that fits really well as a policy, as work moves through that value stream. So as we go from one state to another, we have a definition of done or a policy that states what it means for that work item to be capable of flowing to that next step in the workflow.
Sam Falco: [22:51] Right. That explicit x, uh, exit criteria from the, from the column, it can be really helpful.
Dan Neumann: [22:58] All right, after that brief digression towards the Kanban Front, we’ll bring it back to Scrum. Thank you for hearing me on that.
Sam Falco: [23:04] Uh, I think the takeaways is start with what you know that you need to do to get to done. Don’t obsess about having the perfect definition of done, especially for beginning team, but even older teams that really need to tune it up, start with what you know, make sure that you have useful guidelines that will help you, uh, communicate what is complete, what is done, what the product does and whether it’s available to ship or when it’s available to ship. And remember that this can limit the cost of technical debt and make your more nimble. We’ll put some show notes on the website with some examples of definitions of done. We’ll, we’ll do one that is, here’s where it starts and here is some iteration and that’ll get some people started.
Dan Neumann: [24:00] You can find those at agilethought.com/podcast. Okay, so Sam, what, uh, what are you reading these days that’s kind of peaking your interest?
Sam Falco: [24:09] My recent read, I just started it last night is “The Enterprise and Scrum,” by Ken Schwaber. That’s as far as I’ve gotten.
Dan Neumann: [24:17] Well I think we’ll, we’ll just put a pin in that for a future conversation on that. I’ll look forward to hearing more about that. Maybe that’ll be my next book. I have finished up “Nimble Facilitation,” by Rebecca Sutherns and that’s the podcast previous to this one that folks can go listen to. So that one’s done for me. Now it’s met its definition of done, and now I need to go off and find the next book, so perhaps it will be “The Enterprise and Scrum” as well. All right, well, thanks again for joining me Sam.
Outro: [24:50] This has been the Agile Coaches’ Corner Podcast brought to you by AgileThought and get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.