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
Was this article helpful?
Thank you for your feedback! Our team will get back to you
