Definition of Done

This document explains the basic processes, how Agile methodology is implemented and the definitions that are included in every project delivery by default. 

As always you want to deliver the best quality service as possible for its customers so modifying, adding and improving the default process is always possible and will be agreed in written between both parties during the contract phase or if needed, can be added later as an addendum for the contract.

Definition of Done - business

Functional	Quality	Documentation /Reuse
Business Value has been defined and is understood. There are clearly defined acceptance criteria. Architecture update and Solution Design has been defined. UX/UI prototypes have been defined and tested.	It is sized appropriately (it can fit into a sprint, smaller is better). The team are confident and agree to commit the item to delivery for the end of sprint. There is a plan to manage the dependencies.	There are clearly defined acceptance criteria. The scrum team to assign the story to is defined and agreed. The story can be estimated (By the Team!) Work has been broken down into tasks.

Definition of Done - UX / UI

Functional	Quality	Documentation /Reuse
Design satisfies the acceptance criteria and business case(s). Low-fidelity prototypes (wireframes) have been approved by stakeholders (PO, PM, DEV, decision makers, requirement analysts, etc.). High-fidelity prototypes (UI screens) have passed usability tests with end-users / specialists with no serious issues. Visual elements have been approved by marketing and / or business stake holders. Design works on target devices (desktop, tablet, mobile) and orientations. Designad heres to existing style guide / design system. If there are new design elements / patterns, they have been added to existing style guide / design system. Design specifications (assets, states, interactions, animations, behaviours, transitions, links, prototypes, artifacts, etc.)are documented and properly shared with the development team.	Design creates the outcomes that users, customers, and businesses seek. Design helps to provide a consistent end-to-end experience. Design meets at least level AA of accessibility guidelines. Design considers potential corner cases, empty states and error states. The copy has been written by, or validated by, a copywriter. It is sized appropriately (it can fit into a sprint, smaller is better).	There are clearly defined acceptance criteria. The story can be estimated (By the Team!) Work has been broken down into tasks. Artifacts: process diagrams, site maps, user journeys, personas, scenarios, prototypes, style guides / design system, usability tests and reports.

Definition of Done - Frontend

Functional	Quality	Documentation /Reuse
All development has been completed. CSS Class's covers all requirements. New business functionality satisfies the acceptance criteria. User Story has been reviewed by TL and TL accepted all open issues if any. All text is implemented using translation keys.	No known defects. No inline CSS. Use CSS variables. No inline JavaScript. BEM convention should be applied	All group of CSS are identified and commented Documentation completed Peer code review Peer code review passed

Definition of Done -Custom Components

Functional	Quality	Documentation /Reuse
All development has been completed. CSS Class's covers all requirements. New business functionality satisfies the acceptance criteria. User Story has been reviewed by TL and TL accepted all open issues if any.	Component should be public. Use Placeholders. Component, Placeholders, parameters and actions must have description. Used CamelCase. No known defects. No inline CSS. No CSS applied directly on the component block. No inline JavaScript. In reactive components, use the "Style Classes" attribute of an element to assign dynamic classes. Components can't have any type of applications logic, only logic that is set for the component's UI. Module can only have references to the base theme and OutSystems UI	All group of CSS are identified and commented. Documentation completed. Peer code review. Peer code review passed. Component tested

Definition of Done - Database

Functional	Quality	Documentation /Reuse
Data Model covers all requirements. Functionalities related with Database has been tested by the developer. All features related with Database have been tested with modern browsers; Chrome, Firefox & Safari. New business functionality satisfies the acceptance criteria. User Story has been reviewed by Architect / TL and Architect/ TL accepted all open issues if any	No Database redundancy. Database normalization well applied. Cardinality well applied. Index's well applied. All tables must have the default fields created. No known defects. Data Model have been designed with scalability in mind. Performance test passed.	All tables and their fields have description. Peer code review. Peer code review passed. Acceptance Criteria met

Definition of Done - Backend

Functional	Quality	Documentation /Reuse
All development has been completed. Functionality has been tested by the developer. All features have been tested with modern browsers; Chrome, Firefox & Safari. New business functionality satisfies the acceptance criteria. User Story has been reviewed by TL and TL accepted all open issues if any.	No error on coding standards, no warnings in service studio and no test code on module. Use OutSystems best practices. Organized code flow. No known defects. No Dependence unattended. In actions is forbidden to have more than 20 OutSystems elements. On horizontal domains only Service Actions are allowed. All CRUD operation should be done with Webhook approach. Unit test coverage of public method > 85%. Regression tested in Chrome, Firefox & Safari in test environment.	All public methods / structures / Complex action are commented. Documentation completed. Peer code review. Peer code review passed. Technical Debts 90

Definition of Done - Integrations

Functional	Quality	Documentation /Reuse
All development has been completed. Integrations has been tested by the developer. All Integrations have been tested with the help of a web screen developed for each integration. New business functionality satisfies the acceptance criteria. User Story has been reviewed by TL and TL accepted all open issues if any.	No error on coding standards, no warnings in service studio and no test code on module. Use OutSystems best practices. Organized code flow. No known defects. ExternalId must be supported for external communications. API method must be a wrapper. No Business Logic.  No Dependence unattended.  Regression tested in test environment.	All API are commented. Documentation completed. Peer code review. Peer code review passed. Technical Debts 90

Definition of Done - Test cases (Manual)

Functional	Quality	Documentation /Reuse
Story acceptance criteria's has been verified as functional. All happy paths (successful execution) have been covered. All unhappy paths (system returns error) have been covered. Exploratory scenarios (think how user could break the functionality) have been covered. Test cases validate the business scenarios

Definition of Done - BDD tests (Automated)

Functional	Quality	Documentation /Reuse
All BDD test scenarios defined to the story have been created. Test case validates the business scenario. Business scenario is expressed in BDD scenario in business language (non-technical). Business scenario is expressed in BDD scenario in Gerkhin format (Given, When, Then). All existing BDD test affected by the changes have been updated	Necessary validations are in place to verify business logic No vague validations (adds maintainability overhead or test flakiness). Test is resilient to data changes (Returned data order changes) No error handling in test steps (So that potential error is thrown to test screen) There's a alphabetical order for screen actions indicating execution order (A_Setup, B_Given, C_When...) Test can be run individually (Change in test execution order does not cause failures) Maximum execution time < 5 seconds BDD test modules run parallel with other test modules Test can be ran multiple times in row

Definition of Done - End to End Test cases (Automated)

Functional	Quality	Documentation /Reuse
All E2E test scenarios defined to the story have been created Test case validates the core business scenario Test case validates the whole business flow (end to end) All existing E2E affected by the story changes have been updated	Necessary validations are in place to verify business logic No vague validations (adds maintainability overhead or test flakiness). Test is resilient to data changes (Data order changes) Test can be run individually (Change in test execution order does not cause failures) Test is resilient to screen changes (prioritizing selector id:s, using xpath contains when finding test data etc) Test runs parallel with other tests Steps have been commented unless its apparent from step selector name Test can be ran multiple times in row

Definition of Done - Test execution (regression)

Functional	Quality	Documentation /Reuse
Unit tests have been executed (incl. regression) E2E tests have been executed (incl. regression) E2E tests have been added to appropriate ghost inspector regression suite BDD tests have been included to test framework regression suite Tests are passing Failures have been investigated	No defects related to story remain Broken tests have been fixed All failures caused by non-story related defects have been raised

Acceptance criteria

Functional	Quality	Documentation /Reuse
Beginner] – Simple description on how functionality should work. Example: “Only show last 2 emails sent to the customer” “When pressing ‘resend email’, show example of email sent”. [Advanced] – Given <precondition> When <scenario> Then <expected result>. Example: - “Given that the customer hasn’t received any emails yet, when agent opens dashboard, then ‘no previous emails’ message is displayed”	User Stories are a set of steps in the business process and must be clearly mapped in its flow The Sprint goal must represent an end-to-end process that is meaningful and can be demonstrated to business as part of the final solution The business process frames the User Story’s definition, business value and expected user experience. This context provides the right level for communication and understanding over what is being built and its impact on other process steps The first conversations during the shaping phase take place around the process – The US details are refined next, based on these conversations. Recommendation: maintain the business process / activity diagram(s) with the US mapped and use it always as context for US definition