Artwork

Content provided by Dave Prior, Agile Consultant & Certified Scrum Trainer, Dave Prior, Agile Consultant, and Certified Scrum Trainer. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Dave Prior, Agile Consultant & Certified Scrum Trainer, Dave Prior, Agile Consultant, and Certified Scrum Trainer or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Creating a Definition of Done: A SoundNotes Tutorial

9:19
 
Share
 

Manage episode 220175130 series 2360784
Content provided by Dave Prior, Agile Consultant & Certified Scrum Trainer, Dave Prior, Agile Consultant, and Certified Scrum Trainer. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Dave Prior, Agile Consultant & Certified Scrum Trainer, Dave Prior, Agile Consultant, and Certified Scrum Trainer or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

One of the most important things you can do for your team is to make sure you have a clearly defined, and well-documented, Definition of Done.

If you’ve ever seen footage of the flight control center when NASA launches a rocket you’ve seen a great example of a Definition of Done. Imagine what it would be like if NASA didn’t have all those stations that had to report in with “Go for launch” or “No Go for launch”. Imagine how that would work if we assumed we all had the same understanding of what "Ready for Launch" actually meant?

In this episode of SoundNotes, Dave Prior is giving a tutorial on how to create a Definition of Done for your team. If you're following Scrum as it's defined, then “done” and potentially shippable are intended to be the same thing. Unfortunately, for many organizations, this isn't something that holds true. For example, your team may require additional integration testing that is done by a separate team and happens outside the Sprint. Yes, it’s dysfunctional from a Scrum perspective. Yes, you should try to fix it, but sometimes you’ve got what you’ve got and you're too fully consumed with other battles.

Over the course of the podcast, Dave talks about having clarity on three different levels of done. Here's what the three levels look like:

  1. Work that is “done” and can be presented to the Product Owner for Acceptance - this is an agreement between the PO and the Dev Team.

Example:

  • Code Complete
  • Test Cases are automated and executed
  • No defects
  • Acceptance Criteria Met
  • Pass Unit Testing
  • Pass Code Review
  • Documentation Complete as defined in Acceptance Criteria
  • Team knows how they will present feature during Sprint Review

2. Work that is “done” and can be presented to Stakeholders in the Sprint Review

Example:

  • Work has been presented to Product Owner
  • Product Owner Accepts as Potentially Shippable
  • Passes Previous Acceptance Tests
  • Demo Ready for Sprint Review
  • No Compile Warnings
  • Bugs Committed in Sprint Resolved
  • Deployment Docs Updated
  • Release Notes Updated

3. Work that is “done” and can be actually shipped to customers.

Example:

  • Published to Stage Server
  • Passes Deployment Testing
  • Deployment Docs Delivered
  • Release Notes Delivered
  • Infrastructure Change Notes Delivered
  • Passes Performance Testing
  • Passes Security Audio

If you don’t have a clearly defined, well-documented Definition of Done that you're updating every Sprint, you're putting your team and your organization in danger. If you don't already have a Definition of Done, you need one...and you need it now! In this episode of SoundNotes, Dave walks you through the creation of a Definition of Done.

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

  continue reading

345 episodes

Artwork
iconShare
 
Manage episode 220175130 series 2360784
Content provided by Dave Prior, Agile Consultant & Certified Scrum Trainer, Dave Prior, Agile Consultant, and Certified Scrum Trainer. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Dave Prior, Agile Consultant & Certified Scrum Trainer, Dave Prior, Agile Consultant, and Certified Scrum Trainer or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

One of the most important things you can do for your team is to make sure you have a clearly defined, and well-documented, Definition of Done.

If you’ve ever seen footage of the flight control center when NASA launches a rocket you’ve seen a great example of a Definition of Done. Imagine what it would be like if NASA didn’t have all those stations that had to report in with “Go for launch” or “No Go for launch”. Imagine how that would work if we assumed we all had the same understanding of what "Ready for Launch" actually meant?

In this episode of SoundNotes, Dave Prior is giving a tutorial on how to create a Definition of Done for your team. If you're following Scrum as it's defined, then “done” and potentially shippable are intended to be the same thing. Unfortunately, for many organizations, this isn't something that holds true. For example, your team may require additional integration testing that is done by a separate team and happens outside the Sprint. Yes, it’s dysfunctional from a Scrum perspective. Yes, you should try to fix it, but sometimes you’ve got what you’ve got and you're too fully consumed with other battles.

Over the course of the podcast, Dave talks about having clarity on three different levels of done. Here's what the three levels look like:

  1. Work that is “done” and can be presented to the Product Owner for Acceptance - this is an agreement between the PO and the Dev Team.

Example:

  • Code Complete
  • Test Cases are automated and executed
  • No defects
  • Acceptance Criteria Met
  • Pass Unit Testing
  • Pass Code Review
  • Documentation Complete as defined in Acceptance Criteria
  • Team knows how they will present feature during Sprint Review

2. Work that is “done” and can be presented to Stakeholders in the Sprint Review

Example:

  • Work has been presented to Product Owner
  • Product Owner Accepts as Potentially Shippable
  • Passes Previous Acceptance Tests
  • Demo Ready for Sprint Review
  • No Compile Warnings
  • Bugs Committed in Sprint Resolved
  • Deployment Docs Updated
  • Release Notes Updated

3. Work that is “done” and can be actually shipped to customers.

Example:

  • Published to Stage Server
  • Passes Deployment Testing
  • Deployment Docs Delivered
  • Release Notes Delivered
  • Infrastructure Change Notes Delivered
  • Passes Performance Testing
  • Passes Security Audio

If you don’t have a clearly defined, well-documented Definition of Done that you're updating every Sprint, you're putting your team and your organization in danger. If you don't already have a Definition of Done, you need one...and you need it now! In this episode of SoundNotes, Dave walks you through the creation of a Definition of Done.

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

  continue reading

345 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide