DoD At story level should include:

 Story is documented
 Code is peer-reviewed
 Code passes SONAR quality gate
 Story is tested and passed against acceptance criteria
 Story passes regression testing
 Code is deployed to test environment
 CI/CD pipeline automation is in place for microservice changes

DoD At feature level should include: 

 Feature is documented
 Code is peer-reviewed
 Code passes SONAR quality gate
 Code is deployed to test environment
 Feature is tested and passed against acceptance criteria (incl. NFRs)
 Feature passes regression testing
 Feature ok-ed by Product Owner
 CPT completed

DOD for AO

When work can be classified as complete by the sprint team

 Unit, functional BDD (acceptance criteria),  and integration tests executed and passed by the CD
pipeline (Unit testing cannot be achieved on the UI side yet, can be completed as maturity
grows)
 All code developed and reviewed to agreed quality criteria (split this into static analysis and 4
eye review)
 Rectify any critical and major defects, acknowledging that minor defects may progress onwards
 Critical (in JIRA - Most Urgent) = Showstopper, blocks functionality completely
 Major (in JIRA - Highest & High) = Functionality not completely blocked but no workaround
available
 Minor (in JIRA - Medium & Low) = Cosmetic issues, not affecting functionality
 Must achieve acceptance by Product Owner
 Regression testing updated, run and passed
 All artefacts stored in relevant repositories
 Met general accepted working practises
 Sonar review
 All NFR testing, including relevant level of performance testing completed and accepted (initial
AO NFRs have been documented here = Always On NFRs)
 Met all Operational NFR’s (monitoring, ... (No Operational NFRs currently defined)
 Deployed into CDT
 Documentation ready and Webmaster notified for movement into PP
Goals
 The main aim of this project is to onboard Schedules, Port Calls and Vessel Schedules into
Always On and draw traffic away from the SSP platform. This allows for greater bandwidth
within SSP and therefore stability for the old platform

Always On Platform Non Functional Requirements

 In addition to the NFRs listed in the Requirements table below, the Always On project
should complete the MGIS NFR template - NFR Template 2.3.docx
 Once completed the document should be sent to MGIS and uploaded here for reference
 MGIS contact for help with completion of this document is Richie Fairless
 The MGIS NFR document covers the following areas: 
 Security
 Support
 Disaster Recovery
 Reliability
 Audit and Controls
 Availability
 Backup

Implications of in Sprint team skills required

o Scrum Master
 Coordinator / Ceremonies / block un-blocker
o Software Design / Dev Lead
 Design Sketch Elaboration, Component Contracts
 Unit Tests
 Development Artefacts
o Developer
 Unit Test Creation
 Development Artefacts
o Business Analysis / (Proxy) Product Owner
 Team support / decision maker
o Technical Tester (DIT)
 Regression test create and execute (via CD)
 Acceptance criteria validation
DoD for SSIB

Pre-requisite information for a work item

We need the following information for a service that is to be integrated to. This needs to be gathered
well in advance of integrating to that service. I will extract this out to a table that is filled out for
each service

 Service name
 Service methods and description
 Service WSDL svn location
 Sample request and response(s) svn location
 Endpoints identified for deployments (for deployment
configuration)
 DEV
 INT
 SIT

Before Item is accepted in to a sprint

 Mock service is created
 Acceptance criteria are identified
 Item is 100% refined
 Item is detail planned
 NFRs are identified

Before developement is started

 Unit tests are created
 Soap UI tests are created
 Regression tests are created
 Automated tests are created
 High level implementation plan is created

Before item is signed off

 Documentation is completed
 Feature is built and deployed to DEV and INT
 Test coverage is met
 Code is reviewed by one or more peers
 NFRS are met
 UX standards are met
 Code quality checks are passed
 Impact of changes are communicated within the team -
(once this goes live and we add features, this will be
critical)
 Automated tests are passed (Optional)
 Manual tests are passed
 Tested on DEV and INT with Real Services
 All defects are closed
 Acceptance criteria are signed off on INT