Working in scrum means that you need a really strong and clear definition of what done looks like. As a scrum master, you need to make sure that everyone in your development team knows what done looks like. This is because the product owner will judge the increment at the end of every sport and will make a call as to whether or not the user stories are actually done. Because the definition of done is so important, the whole development team needs to come together with the scrum master and product owner to figure out what your definition of done is. Sometimes, the organization will already have a definition of done in place and if they do, you should either begin with that or adapt it to fit your team or simply use it out of the box. Having a well defined definition of done is helpful for a few reasons. Team members can use it to judge if they have completed user stories and teams can use it to understand how many product back log items they can pull into a sprint back log during Sprint Planning. So, what should your definition of done look like. Well, you may want to consider different definitions of done for different levels of work. One of the common ways of dividing work is to think of user stories, which make up features, which make up epics. User stories are the most granular level of work. When you add a few of them together you create a feature of your product or service. The entire product or service is an epic. You need to figure out what done looks like at every level. While every team would want to work to their own definition on done, there're serious benefits to getting the increment of state of done done at the end of every sprint. Something is done done when it is ready to be released as part of a feature instead of simply being complete and stored. In this sense then, a number of user stories need to be done done by the end of the sprint. One way to do this is to build and testing at every part of the design and development process. Don't wait until the end of the sprint to test. Test constantly. If major issues crop up because of the testing, you'll also be able to create a list of impediments which if removed will really increase the productivity of the team. So, by testing early, productivity over the long term can be increased and full features rather than just user stories can be delivered at the end of each sprint. That's it for this video. Being a scrum master means that you need to have a really clear idea of what the definition of done looks like for your team. You also need to make sure that they all know what that definition is. It shouldn't ever be ambiguous. Last up. During a sprint, you should aim to get a number of stories done done by testing them throughout the sprint. This will allow you to release usable features at the end of every sprint instead of only completing stories.