Definition of Done : Definition, Examples and How It Affects Agile Projects

Definition of Done (DoD) – Definition

Definition of done is the key to an effectively performing Scrum team.

The Definition of Done and user acceptance criteria (functional acceptance) are orthogonal for a feature. It is a complete checklist of value added and essential activities that emphasize the worth of a feature and not the performance of that feature. Definition of done is well-versed by reality where it captures activities that can be committed by the team to be completed at each level (feature, sprint, release).

DoD is Dynamic and an Auditable Checklist

Characteristics of DoD 

The following list of Characteristics of DoD guarantees the delivering features are originally prepared, with respect to the quality and not with reference to the functionality.

  • DoD is a record for a series of treasured activities mandatory to create a software. List of actions that augment the evident value to the product includes, design documents, coding, coding explanation, release notes, unit and integration testing etc.
  • The project team basically executes reporting through the DoD. In a colloquial way reporting is the facility to convey that the “task is completed.” As we know a characteristic or Product Backlog Item is completed or pending to be completed. DoD clarifies the ambiguity to the “Feature’s done” statement. DoD is used as an indication by the project team to successfully communicate to the other stakeholders.
  • DoD is conversant by the reality. During every sprint, Scrum wants to know if the teams deliver “successfully shippable software”. In a perfect scenario, successfully shippable software is the product that is available to be shipped to a purchaser within two days. Ideally, DoD and successfully shippable software are one and the same.

DoD at different stages/levels

When teams are working towards perfect scenario, then DoD can have different stages/levels as mentioned below.

  • Feature – Definition of Done (product backlog item)
  • Sprint – Definition of Done (gathering of characteristics designed during the sprint)
  • Release – Definition of Done (successfully shippable state)

Factors influencing the need for an attribute, a sprint or a delivery – DoD. 

Possibility of doing DoD for each attribute

Or

Possibility of doing DoD for every sprint

Or

DoD for release!

It is recommended that if it not possible to carry out DoD for a feature/sprint, teams must, “Identify the obstacles that hold each sprint from being released.”

Reasons for certainty include:

  • The team lacks the required skills for integrating the actions into a definition of done for an attribute/feature or for a sprint.
  • The team is capable, relevant tools are not available such as servers, automated build, and continuous environment for integration.
  • The team is capable and has the right tools but execute the sprint as traditional mini waterfall methodology.

The DoD authenticates whether all responsibilities are taken into account (time left behind), after every sprint or feature is completed., It is used as a record for a series of activities to confirm if all required actions considered important for the project is done.

Responsibility of the team in deciding the DoD

  • Not all required actions need to be valid to every attribute as DoD is planned to be a complete checklist.

It must be deliberately decided by the project team regarding the validity of actions on attributes based on the situation.

For example, (Web Service) user experience strategies for an attribute that offers interface point to another system is not valid to that attribute; but, for other attributes inside the system that performs the integration manually, must follow the user experience strategies.

Definition of Done – Examples

How to Write DoD?

Acceptance Criteria reviewed:

  • Acceptance Criteria for all completed work is collected.
  • Regular criteria are pulled out and used for the general purpose
  • These regular criteria are kept as the base for a DoD.

Technical Debt Measured

  • Any rework required to be completed is identified.
  • Specific reasons are identified as to why this was not done correctly during the first attempt.
  • Steps were taken to completely avoid doing the same work again, and to make sure things are done perfectly during the first attempt.
  • Definition of Done is updated with these corrections.

DoD updated as a continuous process

  • Review and identify the rejected work or the reason for rework within every Sprint.
  • Reconsider and check the DoD for importance and wholeness in each Sprint.

While there is no specific format for a Definition of Done, we can make use of the above-mentioned steps fully or partially based on the need. This makes the definition adaptable according to the situation. Instead, a straightforward list could be made.

Let’s see few examples for the Definition of Done:

Example 1: Set of criteria for the Definition of Done

  • Code review by the peer.
  • Deployment of code to test atmosphere.
  • Attribute passes acceptance criteria test.
  • Regression testing for the attribute.
  • Smoke test for the feature.
  • Documentation is carried out for the feature.
  • UX designer shows a green flag to the feature.
  • Product owner accepts the feature

Example 2: Acceptance Criteria Format – DoD

  • User story requires a modification in the code change
    • “When” Unit tests code is completed for the user story “and” that modified code is checked “and” that modified code is accepted by the reviewer “and” all unit tests are executed “and” no unit tests remained not working “and” that modified code has been dedicated to the depository “and” cleared QA testing successfully “and” it has been approved by the Product Owner.
    • Such a user story will be accepted as completed and sent to production.
  • User story requires the formulation of credentials
    • “When” the credentials reviewed “and” the credentials accepted by the reviewer “and” the credentials approved by the respective Product Owner
    • “Then” that user story is accepted as completed and the credentials edition will be revised.

Example Sourced from: https://dzone.com/articles/definitions-done-practice

 Example 3: List Format – DoD

Stage 1: Code changes:

  • Unit tests completed (printed and cleared).
  • Reviewer reviewed and accepted the code.
  • Code sent to source
  • QA completes testing.
  • Product Owner approves the code changes.

Stage 2: Credentials:

  • Reviewer reviewed and accepted the credentials
  • Product Owner accepts the credentials.
  • Edition/Version number revised.

In the above 3 examples, the criteria make sure the excellence during the growth process and reducing the quantity of work the team must do by going away to fix things that did not happen correctly during the first attempt.

The Product owner is the ultimate decision maker to decide that the feature has adequately worth to be accepted ‘Done’.

 

Follow the links for real-time examples

  1. DoD Exercise
  2. Definition of done in JIRA
  3. An Example from a Game Studio

Impact of Definition of Done on Agile Projects

Agile methodology means tasks have Sprints or iterations which are shorter in length (Sprints/iterations can differ from 2 weeks to 2 months) amid which pre-decided components are created and delivered. Agile tasks can have at least one iteration and deliver the entire item toward the finish of the preceding cycle.

We have been reading about DoD for quite some time now, and to reiterate DoD is Dynamic and an Auditable Checklist.

Criticism enables to learn, improve, and attain the goal much successfully. It’s critical to get such criticism early and often, and this can be facilitated by iterative development. When I say, criticism is sounded odd but criticism here is nothing but feedback. The actual feedback obtained is described in the Definition of Done.

Reasons of how Definition of Done affects Agile Projects.

Reason #1

opinion and enhancement

  • A completed Definition of Done will outline all steps needed to release a completed increment, thereby it creates feedback about the product and about the procedure inside every sprint.
  • Feedback of the product is generated in the sprint along with the demo, performance and acceptance testing.
  • During the demo, feedback is given by the product owner.
  • When all criteria are implemented, a complete feedback is generated by the acceptance tests about the validation of the acceptance criteria.

More feedback about the procedure is obtained during the evaluation and deployment done across the team.

Image Courtesy

Greater the number steps in the Definition of Done, greater is the feedback received, which help an agile project to be delivered on time as per the product owners specification

Reason #2

Release planning is improved with DoD

  • Different items are left undone even after a sprint is done.
  • Bugs are not yet been cleaned completely.
  • Integration testing not done
  • Performance testing not done,
  • User manual update is not completed.

Image Courtesy

  • During an Agile project delivery schedule sitting, depending on the number of user stories points and velocity a delivery plan is strategized.
  • E.g. When there is twenty-two user story points and speed of 6 in the given direction need to be executed, a minimum of 4 sprints is required before the scheduled delivery date.

Image Courtesy

  • The actual difficulty is the work will not be completed even after completion of four sprints. This is fixed by introducing “tightening sprints” or “delivery sprints.” These sprints are used to, solve some last bugs, create the operation packages, or to perform final testing, to prepare the program available for production.

Image Courtesy

  • Despite these being a bad Agile practice, delivery date, and delivery planning never match.
  • It now depends on the “intended” sprints along with a couple of more additional delivery sprints, in the place of planning the release based on sprints.

If the agile team efficiently describes and executes the Definition of Done, all the problems are fixed and work is completed inside the sprints and release sprints are not required.

Reason #3

Definition of Done reduces the delay of risk

  • With a complete Definition of Done, executing every step required to bring a rise preserving the finest value, you are reducing the delay of risk.
  • All steps in the Definition of Done are administered to comments and hence unsafe components are reviewed, modified, and upgraded as much as possible in the sprints in the early stage.

Reason #4

Definition of Done characterizes the Quality – excellence, Maturity – readiness and Agility- quickness of the Scrum team

  • Any team can finish any new attribute within one sprint and deliver it instantly to production, provided it complies with all the footprints described in the DoD, required to pledge the most excellent value.
  • The alertness basically is the speed of the team to deliver an attribute to production in every sprint.

The worth of the team is denoted by the number of footprints in the DoD that are functional when delivering this attribute for production.

 Conclusion

The Definition of Done is a noteworthy Agile practice to help the teams to plan and execute work.   A good Definition of Done will support the agile projects in getting feedback and enlightening product and process.

Definition of Done – Checklist

☐           Acceptance defined criteria for all user story
☐            Unit tests printed and approved
☐            Code compiles with no errors and no warnings
☐            New code doesn’t break existing code
☐            Test case review (Dev to review test case written)
☐            Architectural impact assessed and artifacts updated if necessary
☐            Comments added in Error codes
☐            Code examined by peer
☐            Code checked in referring to US# /Task#
☐            Tested on FE
☐            Integration test was written & passed
☐            Test code reviewed
☐            Environment requirements documented
☐            Interface document updated/added and checked into SVN
☐            Acceptance criteria verified complete
☐           All PI-P3 bugs for the story are closed
☐            Test approves user story
☐            Story demonstrated to product owner

Reference: 

  1. How Agile Teams Should Use the Definition of Done
  2. How to build DoD
  3. Creation of DoD

 

 

Leave a comment

Your email address will not be published. Required fields are marked *