‘Potentially Shippable’ gives a state of ‘confidence’ that what we developed in the Sprint is actually ‘done’. Also, it indicates that the built product doesn’t have any ‘undone work’ and is ready to ship. If the Scrum teams have produced potentially shippable product, there must be a well-defined, agreed-upon “Definition of Done”.
DoD is a checklist of the work types that the team is supposed to finish successfully before declaring the work to be potentially shippable. These work types depend on a number of variables like:
The Definition of Done (DoD) can vary, but it is crucial to make sure that the initial Definition of Done is agreed upon before the first Sprint. According to Scrum Alliance, there are three different types of DoD, mentioned below.
Well, the team members are using DoD as a good reporting tool as it specifies that ‘the feature is done’. It is easy for a team member to communicate the update to the other team members and the Product Owner. Below is an example of ‘Definition of Done’ checklist.
Mostly, a bare-minimum Definition of Done should produce a complete set of product functionalities includes designing, coding, integrating, testing, and documenting, which at the end will result in delivering a validated value to the customer. However, the tasks can be further refined to get a more specific checklist.
E.g. What is testing? What is Unit testing, Integration testing, System testing, Platform testing and many more testing types required for the product? Are all the testing types included in the DoD?
If you skip any important type of testing during the sprint, say performance testing, then are you going to skip the testing for now and will do it after some time? If so, you will not say that you have built a potentially shippable product this sprint, as performance testing is crucial to being ‘done’. Also, when you do performance testing later, it doesn’t work according to a plan. Sometimes, you need to spend more time and money to resolve any critical problem to get it ‘done’.
Scrum teams should exhibit the confidence that whatever they build is of the best quality and shippable. This constitutes a robust ‘Definition of Done’.
As discussed in the previous blog , during a sprint each product backlog item should satisfy a set of conditions (acceptance criteria), stated by the Product Owner. These acceptance criteria are ultimately verified in the acceptance tests. E.g. if the product backlog item is- “A customer wants to purchase the clothes online”, the choices of shopping websites might be “Shopping from Amazon, Flipkart, Myntra, and Jabong”.
So, each Product Backlog item has a suitable set of acceptance criteria. The DoD is applied during a Sprint to the product increment that is yet to be built. The product increment is nothing but a set of the product backlog items and each product backlog item must conform to the definition-of-done checklist.
A product backlog item can be said ‘done’ if and only if the item-specific acceptance criteria (e.g., “all shopping options are allowed”) and the sprint level definition-of-done (e.g., “live on the production server”) have been met.
Some teams have embraced the notion of ‘done’ vs ‘done-done’. Done-Done is supposed to be more done than just done in some ways. Teams use this term to convey that the task performed during the Sprint is really done. The task is done to the point that the customer could think that the work is ‘done’ (potentially shippable product).
The Scrum teams that use ‘done-done’ to convey “we performed as much work as we were prepared to do!” But the fact is well-performing Scrum teams don’t need those two concepts to exhibit their performance. For such teams ‘done’ really means ‘done-done’.