Defintion of done
Defintion of done

Course Description

This module takes a deep dive into everything that makes sprint planning effective, including having a strong definition of done, how to use velocity and capacity to your advantage, and how to deal with impediments.

Learning Objectives 

The objectives of this course are to provide you with and understanding of: 

  • What sprint planning is
  • How to create a strong definition of done 
  • What velocity and capacity are, and how to calculate them 
  • How to deal with impediments  

Intended Audience 

This course is aimed at Scrum Masters who want to improve their individual knowledge of facilitating scrum events in service to their Scrum team and their wider organization 


There are no specific pre-requisites to study this course 


We welcome all feedback and suggestions - please contact us at to let us know what you think.


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.

About the Author
Learning Paths

Tony has over 20 years’ experience in Business Development, Business Change, Consulting, and Project/Program Management working with public, private, and third sector organizations.

He has helped organizations to design and create processes and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider, utilizing a wide range of methods and frameworks to provide structure whilst promoting creativity and innovation.

As a confident and self-motivated professional with excellent communication skills, Tony is able to bring people together and get them working as a team quickly.

Tony is an Agile and Scrum trainer with a vast knowledge spanning IT Systems, Business Change, Program and Project Management. With excellent presentation skills and a solid background, he ensures that all clients gain maximum benefit from his training. He has successfully guided those new to the industry through their initial training, helped experienced staff as they progress in their careers, and worked at the director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.