How to write DOD (definition of done) or definition of ready for ML tasks?

Question

As a non technical product owner I realized so far that the nature of ML tasks is a bit different than front or backend tasks. I've been struggling to write a definition of done for ML tasks. so far we separated the research/prototype phase from implementation on the product. even though it helped a bit to understand if something is feasible at all or how it is going to get implemented one problem which remained unsolved was how long the implementation is going to take. and we have a necessity on time to market and cant afford to have forever ongoing tasks. How can I write appropriate definition of done for ML tasks which will consider the nature of its work and doesn't have a open ending?

Answer 1

What a "Definition of Done" Should Accomplish

Ideally, a good Definition of Done has three related goals:

1. Encapsulate the baseline criteria and routine activities required for each Increment to be successfully delivered.
2. A clear description of how each specific Increment will be evaluated, allowing the team to plan against the evaluation criteria during Sprint Planning, and continuously assess their progress towards the Sprint Goal throughout the remainder of the Sprint.
3. Ensure the Scrum Team remains aligned on delivering a potentially-shippable Increment at the end of each Sprint.

If the team isn't planning with testable criteria in mind then they are unlikely to deliver a coherent Increment that is fit for purpose. Even if you aren't practicing test-first development, you should at least be practicing test-first planning by having a set of invariant requirements that will apply to all Increments.

Breaking Down the DoD Goals

Baseline Criteria

The first item is typical quality control stuff. As generic examples, most Definitions of Done will include variations on things like:

1. The Increment will have unit tests for all new code.
2. The Increment will have executable documentation in the form of behavioral tests written in clear Business language,
3. The Increment will be successfully tested in the QA environment.
4. The Increment will exhibit no regressions.
5. The Increment will meet the Sprint Goal defined during Sprint Planning.

In other words, these elements will be the same regardless of the current Sprint Goal or the Increment being developed. They are the minimum, invariant success criteria for all work.

Evaluation Criteria

The second goal of the Definition of Done will be more specific to each particular Increment. Since an Increment should be a thin vertical slice, the Sprint Goal should reflect a measurable objective that can be tested.

For example, if the current Sprint Goal is to deliver a data set for use in modeling during a future Sprint, then the Definitin of Done for the Increment might include:

1. Determining the optimum size of the data set.
2. Defining how the data will be stored and retrieved.
3. Documenting the procedures for loading the data set, including data cleansing and any ETL work that may be required.
4. Developing executable tests to validate each of the items above.

Unless the whole team is working together with a clear definition of success for the current Iteration, the Sprint will lack coherence and the Increment will likely be untestable or unshippable at the end of the Sprint.

Maintaining Alignment

Each Sprint must have a singular Sprint Goal that provides a central coherence for the Increment. The success criteria for the current Increment (above and beyond the generic "doneness" required for all Increments) must be clearly articulated as part of Sprint Planning.

The whole team must agree on what "done" means for the current Increment. This enables them to collaborate on the testable Definitions of Done for the potentially-shippable elements that collectively comprise the current Increment. It also helps the team align on what needs to be done to ensure the functionality of the Increment is testable, and that all planning is based on passing the tests defined within the Definition of Done.

Without this alignment, and without all team members thinking about dependencies and tests before work on the Increment begins, the ability of the team to synchronize during the Sprint will be compromised. The Definition of Done is not only there for quality control, but is also an essential part of helping the team to decompose work and communicate effectively about how to track the effectiveness of the Sprint and the suitability of the Increment during both planning and development.