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.

The types of tickets we decided are: Feature, Task, Bug Fix, Spike, Epic. Below are the brief description and requirements for DOR for each type of ticket.

General

These should be fulfilled in all types of tickets:

• 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:

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

Now we will explain each ticket type, as well as the additions and special cases to DOR for each type.

Feature

Features are tickets, where we develop a new functionality or extend a functionality. A feature ticket could be about improving the experimental pipeline, standardizing data preprocessing, creating an online demo, or automating the evaluation step. Typically, these would involve finalizing a repeatable/re-runnable deliverable, for example, written code.

In addition to the general criteria, in a feature ticket:

• The acceptance criteria should clarify unit tests and integration tests even if there are none.
• The outcome should clarify the deliverables (code, process etc.) and documentation, where applicable.

Task

Tasks are ad-hoc or one time jobs. Exploring data/results, re-running experiments, creating a demo, creating visualizations, or writing a blog post may all be considered as a task.

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

Bug fix

A Bug fixes is a correction to an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

• Bug fixes have a Steps to Reproduce

Spike

Spikes are research tickets, where we try to define a problem, identify possible solutions, or try out a new tool/method. Spikes typically answer how we should progress on an issue, e.g. how to complete a task or which feature to implement.

Epic

Epics are tickets which group other tickets with relevant aims. Epics have to align with Sprint goals, or a recurring type of work (e.g. "Management tickets"). Each ticket should have a single epic.

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