Definition of Ready

Definition of ready (DOR) indicates what a ticket needs to cover to be considered as complete for someone to start working on.

The definition of ready facilitates the communication and understanding about the ticket such as its scope, solution method, and deliverables. DOR should be built over the agreement between team members to disallow ambiguities. The DOR may change as time passes, due to a better understanding of the work requirements or changing needs.

The current DOR has been created from the discussions, which took place in Sprint 0 between @sertansenturk and @hedonistrh.

Below are the brief description and requirements for DOR for each type of ticket.

General

These should be present in all ticket types for DOR:

• Pointed (except Epics, see below)
• One of the types below added as a label
• Assigned to a person
• Added to a Sprint
• Dependencies linked (if applicable)
• Team understands and agrees upon the content & context
• Labeled as Ready

All tickets have to adhere to the structure below (Additions/Special cases will be described for each type later.):

• One-line summary (optional)
• Reason
• Design
• Acceptance Criteria
• Outcome

Features

Features are tickets, which we develop a new functionality or extend it within the scope of the project. Some example features could be improving the experimental pipeline, standardizing data preprocessing, creating an online demo, and automating the evaluation. Typically they would involve finalizing a repeatable/re-runnable deliverable, e.g. code.

In addition to the criteria for general tickets, a feature ticket should include

• Acceptance criteria should clarify Unit tests and Integration tests even if there are none.
• Outcome should clarify deliverables (code, process etc.) and documentation, if applicable

Tasks

DescriptionXX

• Outcome should clarify deliverables (code, process etc.) and documentation, if applicable.

Bug fixes

DescriptionXX

• Bug fixes have a Steps to Reproduce

Spike

DescriptionXX

Epics

DescriptionXX

• Epics have the only description
• The epics should not be pointed. Its overall point is the summation of all points of related tickets.

Possible stories

Bug fixing -> Bug Fixing

Problem definition/refinement/elaboration -> Spike

Experimentation
	Running the experiments -> Task
	Model evaluation -> Task

Data Ops
	Data exploration -> Feature/Task
	Dataset creation -> Task

Visualizations (Data, Results, Model/Methods...) -> Task

Documentation generation
	Blog -> Task
	Academic Paper -> Task
	Docstring

Research -> Spike
	Tool/functionality review -> Spike
	Literature review -> Spike

Application -> Feature/Task/Spike
	Music Synthesis
	Demo

Means to an end Coding related Feature Development -> Feature Task completion -> Task Bug fixing Testing

Ticket types

Task
	Reason
	Steps/Design
	Acceptance Criteria
	Outcome
		Deliverables, if applicable
		Documentation, if applicable

Spike
	Reason
	Steps/Design
	Acceptance Criteria
	Outcome

Bug fix
	Reason
	Steps to Produce
	Steps to Fix
	Acceptance Criteria
	Outcome

Epic
	Description