 Hi, I'm Geoff Watts and welcome to another lightbulb talk. This lightbulb talk is about the definition of DUN. One of the hardest aspects of agile delivery frameworks like Scrum to get people's head around is this concept of DUN. The easiest way that I've got to explain it is through the story really from my own experience. I was working in a client quite a few years ago. They started doing Scrum because in their words not mine, things couldn't get any worse. So, what the hell? Things were pretty demoralised at this client, shall we say. They hadn't really had a huge amount of success for a while and within, you know, a few weeks of doing Scrum, things had already picked up. The team were pretty excited looking forward to the sprint review. Come the sprint review, the team got to demonstrate everything that they'd done over the last month and we're talking about six, seven features and the prototype note was sort of blown away and she said, wow, you guys are amazing. Scrum is amazing. Geoff, you're amazing. I know. I've had nothing from you for like a year and now just because we've started doing Scrum, in a month I've got six or seven features. This is brilliant. You know, I give this to my users on Monday. They're going to love it. Suddenly, the development team's faces looked, I'll say panic. Whoa, whoa, whoa. Who said anything about giving this to your users? When we said we were done, we're not done done. And the product owner said, well, what do you mean by done, done? And the development team explained, well, it kind of works on our machines, but this stuff over here, that's not really there. We've just sort of pretended that's there to just show you what we've done. You can't actually go and deploy this yet. And the product owner looked absolutely crestfallen. She said, well, that's no use to me. I mean, don't bother showing me stuff unless it's done, done. And she's got a point. You know, unless something is potentially deployable, it's really no use to our product owner, to our customers. They can't use it, which is one of the reasons why this concept of done is so important. So there are a couple of aspects to the term done, really. But the first thing to bear in mind is that as far as scrum is concerned, it's got to be potentially deployable, potentially ship, potentially usable. You can push the button and on Monday morning, your users could start using it. If the product owner wanted to do so, they don't have to, but you could. So the first thing really is that done should encompass the whole life cycle of the product. So if our product was software, then done should include some design. We don't have a design sprint. OK, so design is included in the sprint analysis. If we need some analysis, some front end works and back end work, any kind of integrations, different levels of testing to make sure that it, you know, the components fit together, it's not going to break anything that's already there. All of that stuff should be contained within done for the development team to be able to say the end of the sprint, we're done. If my product was a book, for example, then my definition of done would be different. I'd have to first think, well, what's my life cycle? You know, what's value? What's potentially deployable at the end of my iteration? If my product is a book, an increment of my product would be a chapter. So my definition of done for a chapter would include some content, obviously. It would include possibly some illustrations. It would include some pagination. It would include spell checking, grammar checking, a consistent type face, all that kind of stuff that would be that would make it potentially deployable. The point of getting your whole life cycle within your definition of done and doing that every sprint is that we can find out where any potential problems are. So if we've got a problem in our testing process or we're not very good at testing and we don't test for six months, we're not going to find that out for six months. We're going to be building up lots and lots of work in progress, not tested stuff. Then we do a big batch of testing, find those problems and we have to go back and redo everything. Whereas if we test a little bit in Sprint One, we'll know where our problems are. The second aspect of the definition of done, really, is our level of quality. This could be the depth of testing, how many levels of testing we're doing. Perhaps it's levels of performance or speed or perhaps the number of browsers that we're compatible with. We can define done now for those can those constraints, those boundaries, deliver to that. And then maybe if we need to expand our definition of done over time. If my products instead of being software or a book was landscape garden, then my definition of done might include the number of weeds visible, the quality of the edging of the lawn. For example, it could be the evenness of the lawn or it could be the directionality of the stripes that I cut through the turf. These lightbulb talks have a definition of done. They all need a title. They should all have a script that's reviewed and edited. They should have a consistent introduction, audio with low ambient noise, a time limit of somewhere between three to five minutes, animation and making sure the audio and the video are lying. It's been published to YouTube, added to the relevant playlist. The automated notification goes out to subscribers. Regardless of what product you're building, whether it's software, whether it's landscape garden, whether it's a book, whether it's a video, bring together the people that are needed to make value happen. Talk through the life cycle, find out everything that's involved in getting from start to finish and capture that in a definition of done. It doesn't have to be perfect. Once you've got an idea of what done might be, start and see what happens. If you've missed anything, we can expand our definition of done over time. If you haven't got all the capabilities to get things done within a sprint, then just note that and make a plan to incrementally bring that stuff in over time. Your definition of done is not a static definition. It changes as the team evolves, as the product evolves. So keep it up to date, keep reviewing it, keep it fresh. As much as you can, try and avoid the differential of done and done done. I hope you enjoyed this light bulb talk. If you did, please like and subscribe. And if there's a topic that you would like me to cover in the future, just add it to the comments. I'll see you next time.