Let's look at the third of Scrum's artifacts, the product increment. The product incremental is the thing being built, produced, developed, or delivered by the developers. Increment is a step toward the Product Goal. Multiple increments will often be needed to reach a Product goal. In delivering each increment, the developers strive to produce work that meets an agreed upon definition of done. This is a set of criteria that must be met for the work to be considered complete. In Scrum terms, that definition have done is the team's commitment for their product increment. As a first example of a definition of done, a software team may agree that work can only be considered done when the code is written and meets coding standards, the coat is checked in, The code fully validated with automated tests, and any necessary documentation has been updated. Let's consider a marketing team for another example. Their definition of done may state that an ad is done when the copy has been approved by the lead copywriter, the ad has be double-checked for spelling and grammar errors, their graphics have been improved by lead designer, and the add has approved the client. and agreed upon definition of done improves communication among everyone on a Scrum team. It also clarifies exactly what the target is for the work of the sprint. Without a definition of done, team members could have varying assumptions about the work to be done in this brand. To see how this works, and since it's getting close to lunch as I record this, let's again use pizza as an example. Suppose you plan to open a new pizzeria. You know you can't just toss some pepperoni, cheese and sauce on a store-bought dough and be successful. you need to come up with a great new pizza recipe for your pizza restaurant to succeed. You start by establishing a definition of done. Let's say that includes tastes great, can be cooked in a reasonable amount of time, and uses only sustainable locally sourced ingredients. But you don't try to do everything all at once. For the first sprint, you establish a goal of determining the recipe for perfect pizza dough. You start with your grandmother's famous pizza-dough recipe and fine-tune it during the sprint. And you offer taste tests to friends and family. At the end of that sprint, you are done thinking about pizza dough. You've met everything on your definition of done. This is your first increment. you've taken a step toward achieving a product goal of having a great tasting pizza you can sell. Next sprint, you turn your attention to the sauce. You experiment with a few variations on Grandma's secret recipe that she entrusted only to you. By the end of the second sprint you've got the perfect sauce to go on the Perfect Crust that you developed the prior sprint. In each sprint the developers incrementally improve the product. With each sprint and each increment, the developers move a step closer to the product goal. To help make this happen, sprints are time-boxed to no longer than a calendar month. Not surprisingly, most teams operate in one, two, three, or four-week sprints, with two weeks being by far the most common time box. Time boxing the sprint creates an appropriate sense of urgency. Not so much urgency that developers rush and make mistakes, but enough urgency, that the team keeps the goal and deadline in mind.