Mike, I must appreciate you for making this video concise and fun to watch. You are the reason why I have succeeded with Agile over the years. Thank you!
Very much on board with this. I often explain it like this: The acceptance criteria are usually about the content of the feature and are readily verifiable to a stakeholder (could be the user from the user story), e.g. it has buttons, it's pink, it's available on Thursdays. The definition of done is about the quality or finish of the craftsmanship on the feature and the process surrounding it, e.g. we have unit tested to so-and-so level, we have received thumbs up from at least one stakeholder, at least two developers have an understanding of the way it works. It then follows that usually Unmet acceptance criteria means feature not finished. Unmet definition of done means technical debt. Extra important to be diligent about definition of done because the receiver will let us know if the criteria for acceptance went unfulfilled whereas definition of done rarely has an active champion outside the team. And for sustainable production we need both upheld.
@@sayedfaiztanvir4733 Thank you for saying this to me, I am very happy it is of use to you. 🧡 My definitions are distilled from some years of experience and a habit of regularly returning to drink from the fresh water streams trickling down the sides of the mountain of the goat. I truly enjoy how we enrich everyone when we exchange and challenge our definitions and understandings like this.
@@Relicarious : Scrum is simple and must be explained and understood in a simpler ways. You have given an insightful lesson on "Definition of done" and " Acceptance criteria"
Dear Mr. Mike, i just find your great video's today. just let you kindly know, i learned alot from your video's. Thank you. Regards, Pedram (The Netherlands)
Your training skills are outstanding. You make everything clear and simple, with your helpful examples and visuals. Excellent work!! Many thanks for making these.
Great explanation! would be sharing this with our team's product owner and scrum master later. thank you Mike! my team tends to confuse acceptance criteria with the solution details.
Thank you for this video Mike, very clear and straight to the important points. I had a good understanding of 'Acceptance Criteria' but wasn't too sure about 'Done', I do now - thank you.
Wow! Very nicely and precisely explained the difference, Mike! Appreciate you making this video to help the larger audience get the clarity of thought and concepts clearer. Thank you!
I wanted to take a moment to thank you for creating such informative videos. Your explanations are incredibly clear and professional, and I appreciate the concise format you've chosen for them. I'm especially interested in hearing your perspective on how to handle urgent bugs that pop up during a sprint, considering the traditional principles of SCRUM that discourage changing the number of tasks in a sprint. Your insights on this topic would be greatly appreciated. Once again, thank you for sharing your valuable content.
Thank you for your kind message, Loutset. I appreciate it. I've added it to my list to make a video on handling bugs but here's a short text answer: If the bug is related to a product backlog item in the current sprint, that bug should be fixed in the sprint. If it's a high-priority bug unrelated to current work and that happens often, a good approach is to maintain a buffer in your sprint that will be used for that type of bug. Just as an example, say 50 hours. Then as bugs are found you subtract their effort from the 50 hour buffer and use that to help stakeholders decide if the bug is important enough to do (since it becomes clear to them that having a team spend 10 hours fixing a bug today means 10 fewer hours available for a later bug). I'll make a video on this too. Thanks for the suggestion.
Such a great video! As a scrum master, it is difficult to lead a team if you are not from the technical profession and participate in writing the definition of done and acceptance criteria.
Thank you Mike for the clear and quick explanation! Could we also say that another difference is that while AC are mostly related to the functional part of a PBI, the DoD is more related to the technical part? When working with teams and writing AC, I often ask questions like "How can the user tell that this feature has been fully implemented?", instead when we must agree on a DoD I ask something like "What should we complete in order to consider our job done on a PBI?"
Thanks, Mike for the crisp video. I have a question. You mentioned an example in the video, "Search Wine" and its Acceptance Criteria is "Search by Wine Type", "Search by price range" etc. What I think, are the items mentioned in the User Stories and how the user will see them as search by options on the User Interface. Please correct me, if I am wrong.
Good question. These are definitely acceptance criteria but they do have implications for the UI. "Search by Wine Type" will need to be in the UI somehow for users to do it. But this doesn't say whether it will be dropdown list of wine types, a set of radio buttons on the screen, or even checkboxes on the screen (so more than 1 can be chosen). Ideally a user story would not specify those UI factors.
Hi Mike. Thank you for this informative and concise video. It will be great if you explain how users stories are written in Project management software and how development team deals with this users stories for development.
Hi Rabih, How you write the actual stories won't vary between different project management software. But you'll enter them differently in each tool. There are too many tools for me to be proficient with them all.
So many pages compressed in simple 5 mins video. Thank you for saving our time :) Sir can you please make a video on how you guide teams from breaking down story points into tasks? I have read many different opinions on this. Thank you!
Will do. I've added that to my backlog. The short answer is that during sprint planning teams discuss the work needed to deliver a product backlog item and identify tasks. Tasks should be no more than a day of effort. Tasks do not need to be estimated but many teams will do so at least initially. The estimates are little more than quick guesses used to help the team decide if the backlog item can fit into the sprint. These estimates can be in good old hours because one person will be doing each task so points aren't needed on tasks. (This is because a big reason to use points is so that people of different skill levels can agree on an estimate, which isn't needed on tasks.) I hope that helps as a start.
@@MountainGoatSoftware Thank you for such an elaborate response and putting it in backlog. I really appreciate it. Actually with my first team, I didn't find any issue because team comprised of mostly mid to senior people. But now, the range has expanded from junior to senior and task level work is going wide on guesses. I find it sometimes hard to bring a balance between this. Seniors accompany junior to improve their knowledge on programming side when such things happen. The better team spirit is not allowing to blow it out of context but I am still looking for better way if any.
If task estimates are often wrong, there are a few things you can do. First, ask questions like, "What has to go right for you to finish in that amount of time?" or "What could make that estimate be wrong (or too low)?" Second, use a technique known as "unpacking." This involves asking a person to name the steps in the work (the subtasks in this case). Then have them estimate the parent task---not the subtasks. Unpacking an item then estimating it has been shown to help.
Compliments, great job! I am PMP and leading SAFe certfied with 10 years on IT projects, but 15 Business projects. So can we sum up and say DoD is more at Product or Releases level, and AC is more Sprint level by Story?
Thanks, Albert. I don't think that description gets it quite right. The items on a Definition of Done need to be true of each product backlog. It's just that they are more universal so we elevate them to the DoD. Think about one like "must be thoroughly tested." I don't want to say that each time for each product backlog item. So it gets elevated to the Definition of Done.
You're welcome. The definition of done is for product backlog items (commonly stories). They can't be for tasks as tasks are too different. A team might have a task of "Hold design review with lead users." That's done when the meeting is over (or perhaps when someone writes some notes). A testing task, on the other hand, isn't done until something passes all tests.
Thanks Mike very helpful. Question: I had a stakeholder recently ask me when to create the DoD and when is the acceptance criteria created? Our product focus was building a corporate-wide supply chain finance/accounting tool. In our PBL we had five « functionality buckets » each one of which addressed a broader customer need/problem. We had a DoD for each « functional bucket. » Our DoDs evolved with each refinement session, so in this context DoDs pertained to the Product Backlog items. Conversely, we identified and finalized our acceptance criteria for Sprint Backlog items during each Sprint Planning session. Is there a better more timely way to do this? Thank you
That sounds like good timing for DoD but I might suggest creating acceptance criteria a little earlier. The DoD should be created early on and refined over time so every dev knows what is required. Acceptance criteria are created during backlog refinement before the user story is brought into the sprint. The goal is to ensure that everyone (devs, Product Owner, etc) knows what the criteria are before we start working on the item.
Acceptance Criteria (also know as Conditions of Satisfaction) should be written by the PO since it is the criteria that must be met in order for the PO to accept the done increment.
Do you have materials dedicated to operational and support teams? Other than using kanban and WIP limits, how else can we introduce or utilize agility for these teams who operate primarily in unplanned work?
Nice and short video. I came across a person he is saying they estimate user story. 1 point = 6 hours. Is that acceptable. Currently I am reading your book agile estimation . Not yet finished.
Hi. Thanks for your comment. The short answer is "Don't equate story points to hours." Here's a blog that explains why: www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours
Great question. No, equating 1 story point to a fixed number of hours (6, 3, 800, etc) is *_wrong_* . If someone does that they might as well just call the hours or days. The point of points is that they are relative so people who perform at different rates can agree on an estimate. A junior and senior programmer can both agree that Item A will take half the time of Item B, but the Senior may be thinking 1 day and 2 days while the Junior is thinking 1 week and 2 weeks.
No, I think they should have the same DoD. Most teams, however, will split an epic (big story) into smaller ones so they don’t work directly on the epic but rather than its parts.
The idea is still the same. A definition of done applies to all (or nearly all) of the backlog items and an item must meet it in order to be considered done. It depends on your product but for a cake shop it might be something like "the batter has been taste tested".
@@MountainGoatSoftware thanks for the feedback. What I have noticed mostly is referring it to more digital goods. But when managing a non-digital product, the definition of "Done" sometimes have an inbuilt dependence. This is because, like your example, cake taste is based on the human sensitive of the tongue.
@@vo-Blog Take a look at this article on a multi-level definition of done that I use with hardware companies. www.mountaingoatsoftware.com/blog/multiple-levels-of-done
Because the Definition of Done applies to everything the team works one (unlike the acceptance criteria for one product backlog item) it doesn't change very often. It is generally documented wherever the team keeps shared information. That could often a wiki or a tool like Notion that is a team home page.
OH! You elevated the common criteria to the DoD?! DoD is universal where as the AC is specific to that card\ticket. Oh, ok, that's easy to understand\explain.
Honest question, do you sometimes have shower thoughts that Agile is just full of bullshit but you just keep those thoughts to yourself and never speak about them to anyone??
Not at all. If it were bullshit, I wouldn't devote my life to it. I've seen agile improve too many teams and the lives of too many developers to think it's BS.
Mike, I must appreciate you for making this video concise and fun to watch. You are the reason why I have succeeded with Agile over the years. Thank you!
Ahh, thank you. I really appreciate that.
Very much on board with this.
I often explain it like this:
The acceptance criteria are usually about the content of the feature and are readily verifiable to a stakeholder (could be the user from the user story), e.g. it has buttons, it's pink, it's available on Thursdays.
The definition of done is about the quality or finish of the craftsmanship on the feature and the process surrounding it, e.g. we have unit tested to so-and-so level, we have received thumbs up from at least one stakeholder, at least two developers have an understanding of the way it works.
It then follows that usually
Unmet acceptance criteria means feature not finished.
Unmet definition of done means technical debt.
Extra important to be diligent about definition of done because the receiver will let us know if the criteria for acceptance went unfulfilled whereas definition of done rarely has an active champion outside the team. And for sustainable production we need both upheld.
Well said.
You have given extraordinary definition and differences. Very much understandable. Appreciate this!
@@sayedfaiztanvir4733 Thank you for saying this to me, I am very happy it is of use to you. 🧡
My definitions are distilled from some years of experience and a habit of regularly returning to drink from the fresh water streams trickling down the sides of the mountain of the goat. I truly enjoy how we enrich everyone when we exchange and challenge our definitions and understandings like this.
@@Relicarious : Scrum is simple and must be explained and understood in a simpler ways. You have given an insightful lesson on "Definition of done" and " Acceptance criteria"
@@sayedfaiztanvir4733 🙏🧡
Once upon a time I heard something like "macro and micro level" - sounds like terms used by a typical manager. Thank you, Mike :)
Reminds me of my economics classes. You're welcome!
Never seen this topic explained so well. Awesome content!
Thank you.
Thank you Mike, great and easy to understand contribution to comon sense in agile wording.
Thanks, Mad Dog!
Dear Mr. Mike, i just find your great video's today. just let you kindly know, i learned alot from your video's. Thank you. Regards, Pedram (The Netherlands)
Thanks, Pedram.
One of the GOATS! thank you Mike ! Love your videos :) Very concise and easy to understand- plain english! love it
Thank you, Charlotte. That means a lot to me.
Your training skills are outstanding. You make everything clear and simple, with your helpful examples and visuals. Excellent work!! Many thanks for making these.
Thank you!
Brilliant, so clear. Thanks. 💗💗
Thank you.
That's the slickest segway to subscribing I've ever seen 👍 great channel Mike
Thanks--I liked it myself. 😀
the end portion was really smart way of demonstrating :)
Thanks!!
I have gone through different videos on DOD. But this was is very insightful, different and practical. Thank you
Thank you
Great explanation! would be sharing this with our team's product owner and scrum master later. thank you Mike! my team tends to confuse acceptance criteria with the solution details.
You're welcome. I'm glad it helps you!
Thank you for this video Mike, very clear and straight to the important points. I had a good understanding of 'Acceptance Criteria' but wasn't too sure about 'Done', I do now - thank you.
You're welcome. I'm glad it helped you!
Wow! Very nicely and precisely explained the difference, Mike! Appreciate you making this video to help the larger audience get the clarity of thought and concepts clearer. Thank you!
Thank you very much.
Simple and to-the-point explanation! Nicely done Mike.
Thanks, Waqas. That's kind of you to say.
Thanks for this simple explanation!
Thanks!
Concise, clear. Thanks
Glad it was helpful!
Just in time to coach my team these 2 ideas, thanks. Awesomely acceptable video and nicely done ;-)
Thanks!
This is such a refreshing video I am looking forward to watching more content
Thanks--that's very kind of you.
Great video with a simple definition. Will be sharing this with my team.
Glad you find it helpful!
I wanted to take a moment to thank you for creating such informative videos. Your explanations are incredibly clear and professional, and I appreciate the concise format you've chosen for them. I'm especially interested in hearing your perspective on how to handle urgent bugs that pop up during a sprint, considering the traditional principles of SCRUM that discourage changing the number of tasks in a sprint. Your insights on this topic would be greatly appreciated.
Once again, thank you for sharing your valuable content.
Thank you for your kind message, Loutset. I appreciate it. I've added it to my list to make a video on handling bugs but here's a short text answer: If the bug is related to a product backlog item in the current sprint, that bug should be fixed in the sprint. If it's a high-priority bug unrelated to current work and that happens often, a good approach is to maintain a buffer in your sprint that will be used for that type of bug. Just as an example, say 50 hours. Then as bugs are found you subtract their effort from the 50 hour buffer and use that to help stakeholders decide if the bug is important enough to do (since it becomes clear to them that having a team spend 10 hours fixing a bug today means 10 fewer hours available for a later bug). I'll make a video on this too. Thanks for the suggestion.
best videos about scrum on the interweb ;)
Ahh, thanks. I appreciate the kind words.
Thank you Mike! Your videos are as great as your books.
Thanks, Chris--I really appreciate that.
Great explanation. Thank you!
Thanks.
Great explanation, would love for you make a video on Defination of Ready and it's relevance in scrum best practices. Thank you
@rachnanj As it happens, a video on Definition of Ready is scheduled to come out on November 1st!
Such a great video! As a scrum master, it is difficult to lead a team if you are not from the technical profession and participate in writing the definition of done and acceptance criteria.
Making sure that everyone knows and understands what it means to be done can avoid a lot of headaches!
Really nicely and simply explained topic, thank you for that, Mike :)
Thank you, Martyna. I appreciate it.
Thanks for the simple explanation. Now I've met my DoD criteria.
😀 Thanks. I'm glad you liked it.
1:43 1:44 sent me this @@MountainGoatSoftware
Thank you Mike for the clear and quick explanation!
Could we also say that another difference is that while AC are mostly related to the functional part of a PBI, the DoD is more related to the technical part?
When working with teams and writing AC, I often ask questions like "How can the user tell that this feature has been fully implemented?", instead when we must agree on a DoD I ask something like "What should we complete in order to consider our job done on a PBI?"
I like that---I think functional vs. technical is a good distinction. Nice!
How beautifully explained
Thank you!
im leaving a comment just cause you added leaving a comment to mu DoD. also cause i was really confused about AC and Dod before this video. thanks
:) Thanks for commenting. I'm glad this was helpful.
Amazing Mike. Thanks it's simple but high value. Thank you very much.
You're welcome and I appreciate your comment.
Great videos, Mike. I teach Scrum and this is very useful tool for students to enhance understanding these concepts..
Thank you!
Thanks, Mike for the crisp video. I have a question. You mentioned an example in the video, "Search Wine" and its Acceptance Criteria is "Search by Wine Type", "Search by price range" etc. What I think, are the items mentioned in the User Stories and how the user will see them as search by options on the User Interface. Please correct me, if I am wrong.
Good question. These are definitely acceptance criteria but they do have implications for the UI. "Search by Wine Type" will need to be in the UI somehow for users to do it. But this doesn't say whether it will be dropdown list of wine types, a set of radio buttons on the screen, or even checkboxes on the screen (so more than 1 can be chosen).
Ideally a user story would not specify those UI factors.
You are the saviour! Such a nice explanation 🎉
Glad you like it!
Hi Mike. Thank you for this informative and concise video. It will be great if you explain how users stories are written in Project management software and how development team deals with this users stories for development.
Hi Rabih, How you write the actual stories won't vary between different project management software. But you'll enter them differently in each tool. There are too many tools for me to be proficient with them all.
So many pages compressed in simple 5 mins video. Thank you for saving our time :) Sir can you please make a video on how you guide teams from breaking down story points into tasks? I have read many different opinions on this. Thank you!
Will do. I've added that to my backlog. The short answer is that during sprint planning teams discuss the work needed to deliver a product backlog item and identify tasks. Tasks should be no more than a day of effort. Tasks do not need to be estimated but many teams will do so at least initially. The estimates are little more than quick guesses used to help the team decide if the backlog item can fit into the sprint. These estimates can be in good old hours because one person will be doing each task so points aren't needed on tasks. (This is because a big reason to use points is so that people of different skill levels can agree on an estimate, which isn't needed on tasks.)
I hope that helps as a start.
@@MountainGoatSoftware Thank you for such an elaborate response and putting it in backlog. I really appreciate it. Actually with my first team, I didn't find any issue because team comprised of mostly mid to senior people. But now, the range has expanded from junior to senior and task level work is going wide on guesses. I find it sometimes hard to bring a balance between this. Seniors accompany junior to improve their knowledge on programming side when such things happen. The better team spirit is not allowing to blow it out of context but I am still looking for better way if any.
If task estimates are often wrong, there are a few things you can do. First, ask questions like, "What has to go right for you to finish in that amount of time?" or "What could make that estimate be wrong (or too low)?"
Second, use a technique known as "unpacking." This involves asking a person to name the steps in the work (the subtasks in this case). Then have them estimate the parent task---not the subtasks. Unpacking an item then estimating it has been shown to help.
@@MountainGoatSoftware correct! Let me blend this thing and see how it goes. Very much appreciated. I learned something new today😃
Very succinct explanation! Thank you!
You're very welcome!
The last part made me understand it best :D
I'm glad it clicked for you!
It wasn't part of my DoD but thank you :)
Perfect!
This was awsome
Thank you.
Compliments, great job! I am PMP and leading SAFe certfied with 10 years on IT projects, but 15 Business projects.
So can we sum up and say DoD is more at Product or Releases level, and AC is more Sprint level by Story?
Thanks, Albert. I don't think that description gets it quite right. The items on a Definition of Done need to be true of each product backlog. It's just that they are more universal so we elevate them to the DoD. Think about one like "must be thoroughly tested." I don't want to say that each time for each product backlog item. So it gets elevated to the Definition of Done.
Brilliant - so clear, thank you. 💗💗
Glad it was helpful!
Great video !
Thanks!
Precise 🫡 thanks sir
Thanks.
Great video!
Thank you
This is an awesome video
Thank you!
Done!
😀
Thank you for yours videos, I have a question, Is the definition of done (dod) for a user story and task are same?
You're welcome. The definition of done is for product backlog items (commonly stories). They can't be for tasks as tasks are too different. A team might have a task of "Hold design review with lead users." That's done when the meeting is over (or perhaps when someone writes some notes). A testing task, on the other hand, isn't done until something passes all tests.
Thanks Mike very helpful.
Question:
I had a stakeholder recently ask me when to create the DoD and when is the acceptance criteria created?
Our product focus was building a corporate-wide supply chain finance/accounting tool. In our PBL we had five « functionality buckets » each one of which addressed a broader customer need/problem. We had a DoD for each « functional bucket. » Our DoDs evolved with each refinement session, so in this context DoDs pertained to the Product Backlog items.
Conversely, we identified and finalized our acceptance criteria for Sprint Backlog items during each Sprint Planning session.
Is there a better more timely way to do this?
Thank you
That sounds like good timing for DoD but I might suggest creating acceptance criteria a little earlier. The DoD should be created early on and refined over time so every dev knows what is required. Acceptance criteria are created during backlog refinement before the user story is brought into the sprint. The goal is to ensure that everyone (devs, Product Owner, etc) knows what the criteria are before we start working on the item.
I like to think in terms of functional and non-functional.
who should be writing the acceptance criteria? often the Prod Owner or a delegate of the PO (which is a BA) does that, any comments?
Acceptance Criteria (also know as Conditions of Satisfaction) should be written by the PO since it is the criteria that must be met in order for the PO to accept the done increment.
Do you have materials dedicated to operational and support teams? Other than using kanban and WIP limits, how else can we introduce or utilize agility for these teams who operate primarily in unplanned work?
Hi, I saw you emailed me, too. So I sent you a few links. Good luck.
Nice and short video. I came across a person he is saying they estimate user story. 1 point = 6 hours.
Is that acceptable. Currently I am reading your book agile estimation . Not yet finished.
Hi. Thanks for your comment. The short answer is "Don't equate story points to hours." Here's a blog that explains why: www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours
Great question. No, equating 1 story point to a fixed number of hours (6, 3, 800, etc) is *_wrong_* . If someone does that they might as well just call the hours or days. The point of points is that they are relative so people who perform at different rates can agree on an estimate. A junior and senior programmer can both agree that Item A will take half the time of Item B, but the Senior may be thinking 1 day and 2 days while the Junior is thinking 1 week and 2 weeks.
Hi Mike, In your opinion is there, or should there be, a difference for the DoD for Epics vs Stories?
No, I think they should have the same DoD. Most teams, however, will split an epic (big story) into smaller ones so they don’t work directly on the epic but rather than its parts.
What will you do for a non-digital product; definition of done.
The idea is still the same. A definition of done applies to all (or nearly all) of the backlog items and an item must meet it in order to be considered done. It depends on your product but for a cake shop it might be something like "the batter has been taste tested".
@@MountainGoatSoftware thanks for the feedback. What I have noticed mostly is referring it to more digital goods. But when managing a non-digital product, the definition of "Done" sometimes have an inbuilt dependence. This is because, like your example, cake taste is based on the human sensitive of the tongue.
@@vo-Blog Take a look at this article on a multi-level definition of done that I use with hardware companies. www.mountaingoatsoftware.com/blog/multiple-levels-of-done
@@MountainGoatSoftware thanks for sharing and it's really informative 👍
Where are the DoD maintained in a Sprint
Because the Definition of Done applies to everything the team works one (unlike the acceptance criteria for one product backlog item) it doesn't change very often. It is generally documented wherever the team keeps shared information. That could often a wiki or a tool like Notion that is a team home page.
Dod is written for all user stories OR for each user story you wrte DoD ?
Definition of Done is for all stories. Acceptance Criteria are for specific stories that need to be met in addition to the Definition of Done.
OH! You elevated the common criteria to the DoD?! DoD is universal where as the AC is specific to that card\ticket. Oh, ok, that's easy to understand\explain.
Great summary! Thanks.
Honest question,
do you sometimes have shower thoughts that Agile is just full of bullshit but you just keep those thoughts to yourself and never speak about them to anyone??
Not at all. If it were bullshit, I wouldn't devote my life to it. I've seen agile improve too many teams and the lives of too many developers to think it's BS.
@@MountainGoatSoftware haha you're man of integrity.
I guess my team is just missing a good agile coach 😉