Definition of Done

Done-ness is defined differently at different stages of development and for different purposes.

The tables below describe the criteria that need to be taken into account by Product Owners (for Team Increment work), by Feature Owners (for System Increment), by Capability Owners (for Solution Increment work), and by Release Managers (for Software Releases).

Please note that when a Product/Feature/Capability Owner, or Release Manager marks a Story/Feature/Capability/Release as Done, all applicable criteria from the Definition of Done are expected to be fulfilled. When that is not possible, or applicable to an item, the Product/Feature/Capability Owner, or Release Manager MUST indicate in the comments why those elements of the Definition of Done do not apply to that Product/Feature/Capability or Release.

Failure to justify the lack of complete compliance with the Definition of Done results in decreasing quality, and increased Technical Debt, so please be very mindful of this Definition of Done.

Definition of Done checklists are mandated to be used at all stages of development. The definition at the Team Increment may be customised to the context of a team e.g. Enabling Team vs Feature Team. Speak to an RTE to arrange this.

Team Increment

Issue Type

Definition of Done

Story/Enabler

Code

  • Supplied with an Acceptable License.

  • Adheres to SKA language specific style.

  • Checked into SKA repository with a reference to a JIRA ticket ID.

  • Passes the CI/CD pipeline including compiling cleanly and being linted with no warnings: Linting.

  • Unit and module tests pass with adequate coverage (>= 75% with the appropriate exclusions for boiler-plate code).

  • Component, integration and system tests (appropriate for the context) pass.

  • Regression tests pass.

  • Outstanding bugs and technical debt have been logged and triaged, Major or Critical severity issues have been fixed.

Artefacts

Code Documentation

Integration

Process

  • Peer-reviewed/approved and integrated into the default branch via GitLab Merge requests.

  • Relevant NFRs are met

  • Satisfies acceptance criteria

  • Accepted by Product Owner

Spike

Documentation

  • Outcomes documented on the relevant SKA platform

  • Documentation linked to issue in Jira

Process

  • Outcomes reviewed by relevant stakeholders

  • Satisfies acceptance criteria

  • Accepted by Product Owner

System Increment

Issue Type

Definition of Done

Feature/Enabler

Child Stories/Enablers

Documentation

Process

  • UX deliverables (where applicable) are usable by end users or their proxies

  • Outstanding bugs and technical debt have been logged and triaged, Major or Critical severity issues have been fixed

  • Satifies acceptance criteria

  • Relevant NFRs are met

  • Demonstrated to relevant stakeholders

  • Accepted by Feature Owner

Spike

Documentation

  • Outcomes documented on the relevant SKA platform

  • Documentation linked to issue in Jira

Process

  • Outcomes reviewed by relevant stakeholders

  • Satisfies acceptance criteria

  • Accepted by Spike Owner

Solution Increment

Issue Type

Definition of Done

Capability/Enabler

Child Stories/Enablers

  • Completed by all teams, deployed and tested in a Continuous Deployment environment (staging environment during Construction).

Documentation

  • Solution Intent or project documentation updated to reflect the actual implementation

Process

  • Outstanding bugs and technical debt have been logged and triaged, Major or Critical severity issues have been fixed

  • Satifies acceptance criteria

  • Relevant NFRs are met

  • Demonstrated to relevant stakeholders

  • Accepted by Capability Owner

  • Any remaining technical debt has been added to the backlog

Release

Issue Type

Definition of Done

Release

  • Delivered items Done and meet Acceptance Criteria

  • Artifacts published in the Central Artefact Repository

  • A short clear description/summary of the release is provided

  • User facing change log provided

  • User facing documentation provided

  • Verification of the functionality, behavior, and performance of user interfaces provided by product, carried out in an relevant environment

  • Outstanding bugs and technical debt have been logged and triaged, Major or Critical severity issues have been fixed.

Formally Controlled Project Documentation

Documents that are matured to the extent that they quantify an impact on safety, security, quality, schedule, cost, profit or the environment should be validated and formally controlled as per the SKA Document Creation, Validation and Release Standard Operating Procedure (SOP) (SKA-TEL-SKAO-0000765). Until such time, the Lightweight Document Process and Repository may used to manage these documents.

Thereafter, these documents must be formally reviewed and placed in the project’s configuration management system. Whilst there is an unavoidable overhead to this we aim to make it as efficient as possible. However, this level of documentation requires you to follow the process in the Configuration Management part of Confluence, specifically: