Today we are speaking about getting things done! What does it mean when we say something is done and how can you and your team get a better handle on the concept for better products? At times, as developers, we might feel like we are done as soon as the code is written and passed, but in reality, there are more steps in the process, and to get to a real state of being finished we need to formulate a proper framework or checklist for being done! This is one of the issues with working with different teams, as responsibility can sometimes get a bit lost, and so putting some time in, to develop an appropriate way to measure completion can lead to fewer issues and confusion down the road. In today's episode, we also look at the important aspects of feedback and corrections, and how 'done' might be a relative term, especially as your products get increasingly complex. So for all this and a few more thoughts on how you can move things into that beautiful 'done' column, come with us, down the Rabbit Hole!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 203. Definition of Done
[INTRODUCTION]
[0:00:00.5] MN: Hello, and welcome to The Rabbit Hole, the definitive developers podcast, living large in New York. I’m your host, Michael Nunez, our co-host today:
[0:00:08.9] DA: David Anderson.
[0:00:10.5] MN: And today, we’ll be talking about the definition of done.
[EPISODE]
[0:00:15.0] DA: Mike, are you done with that yet?
[0:00:18.0] MN: Am I done defining the definition of done? No. I think we need —
[0:00:22.1] DA: Are you done with the podcast?
[0:00:23.6] MN: I’m not done, no, no. The definition of done on the podcast is not done. We’re not done here. Today, we will be defining what is the definition of done and how to use it in your team to determine whether the features, or the epics, and the stories you’re working on are done and finished.
[0:00:44.4] DA: Okay. What does it mean to be done with something? Like, I got a good product manager, they’re very kind to us and they write out like a very good list of exceptions criteria, like all the features that they want in there. Then I write up the code, and then I’m done with the code. I think I’m done.
[0:01:05.7] MN: So you’re done, yes. But is the feature, are we putting the feature to rest, putting the final nail in the coffin, looking away at the horizon for other features that need to be built? That’s the definition of that. I’ll try to read this definition. I believe it’s from the productplan.com states the following. I’m going to try to do this in one take. Let’s go. “The definition of done is an agreed-upon set of items that must be completed before a project or user story can be considered complete. It is applied consistently and serves as an official gate separating things from being in progress to done.”
[0:01:49.7] DA: Okay. You’re right. I should send it for code review and I guess after I got the code review, I got to merge it.
[0:01:58.9] MN: Yeah, okay. Then you merge it and then you’re done. Yes.
[0:02:02.3] DA: I’m done, yeah. That’s great.
[0:02:06.1] MN: You’re done. You know the thing that happens a lot, times that I’ve seen is that, as engineers, that’s how we feel. Like, “Yo, bro! I finished.” The product person say, “Oh, this is good and we done. I’m done. I don’t know about that feature but I am done.”
[0:02:23.5] DA: I mean the rest of it is just up to fate. Yeah.
[0:02:31.1] MN: Just leave it up to fate.
[0:02:32.1] DA: It can kind of depend on the organization too, because sometimes like you merge and then maybe there’s another team that does deployments, there’s another team that does testing and you got to do a hand off. Maybe like there’s another swimlane on your like your Kanban board in Jira or whatever system you’re using and you just drag it over. Okay, it’s ready for QA. Done.
[0:02:59.3] MN: So the dev is done, right? But then as you mentioned, it could be — in this is a particular example. You have QA who’s going to do the QA testing for this particular feature. Is the feature done? No. Is the development work for that feature done? Yeah, I guess. Until that — a QA person comes back to them and says, “Hey! Hey! Wait a second. This form, when I put numbers in it, it’s broken. It breaks everything. There’s a problem. What are we going to do about this?
[0:03:27.1] DA: Well, that is a new thing. Now, I will open a new. I did the other ticket, now I open a new ticket.
[0:03:32.2] MN: Well, you got to fix it, like it has to get fixed.
[0:03:36.0] DA: Yeah, that’s true. I guess it doesn’t really work. But yeah, I guess that’s why like some people like to say that there’s a difference between something being done versus done-done.
[0:03:50.1] MN: Yes, the done, done.
[0:03:52.6] DA: Yeah, because any one thing can be done or any one step or like part of it, you could be like, “Okay, yeah. I’m done with the coding,” or, “I’ve rebased it and merged it and got it ready.” But like as a team, we should have a shared understanding of like what is that means to be like done-done for real.
[0:04:16.7] MN: Yeah, it is ultimately up to the team. All right, let’s use the same example. You’re done as a developer, you pass it off to QA, QA tries to do a SQL injection on this form field that you have, try to use Bobby's table semicolon. But it’s unsuccessful Dave because you thought ahead and realized you want to block SQL injections from happening into your form fields.
The QA takes it and they say they’re done, and they put it over onto the staging environment to make sure that everything works fine, it’s not broken. Then you show it to the stakeholders who may want to check the feature before it goes and gets released to your users. One of the stakeholders says, “Hold on a second. I realized this form may not be a good place for it, maybe we want to put it at a different place. We want to move it into somewhere else or whatever.”
You can add so many “dones” if you will to this list of your definition of done. You can have a done, done, done or a done, done, done. You and the team need to figure out the steps necessary to do the proper handoff, so that there’s minimal blockage of the process, as well as getting the features out to the user entirely.
[0:05:29.9] DA: Right. I mean, yeah, because in the end, you do have to deploy to production and maybe like a user should also be able to use it as well, that would be great.
[0:05:41.4] MN: Yes.
[0:05:42.4] DA: So either, if you have a feature flag, you should tag all the feature flag, get ready to roll it out. Or maybe do a communication to end users, update the documentation or do an email blast, like, “Hey, everybody. It’s ready.” Because if nobody’s using it, then what’s the point of being done?
[0:06:07.5] MN: Exactly. I think this is something that your team is going to define. I can see as you mentioned, Dave, let’s say there’s a brand-new feature and you want your end-users to use it. You would probably do an email blast when necessary. Say there is a particular like fix that you want to have, maybe not — your definition of done for particular things may not always need an email or that your end users have to use it. But the idea that you are fixing things up, and you have the definition of done, you and the team know you fully completed it, everyone did a proper handoff, everyone’s got their eyes on it, it’s been deployed successfully. And you have done your work, then you can finally drag that bad boy of a card over to the done column.
[0:06:58.8] DA: Although, like, if you’re the product manager and you’re thinking about the feature and like, “Is my product —” maybe there’s an individual feature, but, “Is my product done? Am I really done? Is this the final form of this feature?” Maybe users got feedback, like you got to listen to that feedback, and you have to iterate, and if you’re really on a team that is like high-performing, and agile, and listening to that feedback, and finding user value in it, you’re going to keep on iterating. The product won’t really be done until it’s like retired.
[0:07:40.1] MN: Yes, that is correct. You’re always going to be constantly going over your definition of done. But for the most part, you’re constantly going through the cycle of identifying when a story is done, and the more stories that you’re — or the more features that you are putting out for your product, the more visible or the more in-your-face that definition of done will be. As long as you and the team are familiar with the steps necessary to do that, defining what’s done, and then putting the story away and then moving forward would be ideal what a definition of done is. As we mentioned before if we wanted to give anyone or everyone a basic template of what is the definition of done, a standard. Dave, do you have an idea what that standard look like really quick?
[0:08:32.4] DA: Like what would I check off on my list of things?
[0:08:36.7] MN: Yeah.
[0:08:39.0] DA: I mean, you got to write code that passes all of the code review, all of the acceptance criteria. Maybe you’re going to do a desk check with your designer, maybe you’re going to do a desk check with your product manager before you merge it.
[0:08:56.0] MN Right. What is a desk check?
[0:08:57.1] DA: Like people coming over and kind of doing a check to make sure that everything looks like generally correct, to try to avoid like rework, like we are talking earlier. I’m like overloading this, I guess.
[0:09:12.7] MN: No, that’s fine. No, it’s good. We’ll go back to do the check list over, but like to have people come over to your desk, Dave, is what you’re saying for a desk check? Or like to use a Zoom call, in the age of 2021?
[0:09:24.2] DA: Yeah, right. Like stay away from my desk six feet away. But yeah, like that could be part of your definition of done. Some teams like will only do the acceptance after it’s merged and deployed to an environment, which could be other steps in your definition of done, like merging it, making sure all the CI and tests are passing, having a product manager or the stakeholders accept it, deploying into production, getting in front of the users and getting their feedback.
I think the definition of done or like that kind of like a checklist is just an interesting tool that you don’t want to get like too heavy weight because you can get really detailed. But again, it can be good to think about like what are the bottlenecks in the process of like getting something out. If we’re like forgetting something or like having some bad handoff that takes too long, like throwing something over at QA. Like maybe being really deliberate about saying, “Hey! Engineers, this is your responsibility to work with the people to get it done, like the QA, the acceptance, whatever.”
[0:10:44.6] MN: Right. Because a lot of times, we may — once we finish punching keys and all our tests are passing and we throw it over to QA, we think that it’s over and we try to move on with the next thing. When in reality, we should be working across teams to ensure that we are properly handling that story, crossed that finish line of done.
[0:11:07.9] DA: I mean, there are some team structures or ways that people work that make it harder to do that kind of smooth handoff and kind of really tight collaboration. But having the checklist kind of shines a light on it.
[0:11:25.0] MN: Yeah. As you mentioned Dave, every team is going to operate differently, but I do think that the checklist, like everyone being aware, the checklist is good. As you mentioned, if I had to run through the checklist really quick, write code, make sure it passes the acceptance criteria, possible desk check if necessary, make sure you got a code review, gets checked, merged. Pass it over to QA, QA does their testing, everything’s gravy, accepted, deploy, get in front of users, get feedback.
Your team is going to take that basic generic checklists and add other things to it, right? You may want to bring in the designer to pair with you as you guys are building things, or maybe your product person may not be available for a desk check, so you would do the staging environment, to do any testing in that regard. The definition of done is supposed to be whatever your team needs it to be, to ensure that you can carry over those features to done so that your users will use it.
[END OF EPISODE]
[0:12:23.7] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers like you find their way into The Rabbit Hole. Never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries, and my amazing co-host, Dave Anderson, and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
