FUJ00234940
FUJ00234940
CONFIDENTIAL
SCHEDULE 13
Digital Development Services
Version History
I Version No.
13.0 Added as per CCN1643
14.0 20/12/2021 Updated as per CCN1667a, CCN1669a, CCN1670a,
CCN1675, CCN1700 and moving all Schedules to
v4.0
V15.0 28/09/23 Updated as per CCN1737.
SCHEDULE [3
DIGITAL DEVELOPMENT SERVICES
1. BACKGROUND
11 Paragraph 10 of the MOU outlined the parties’ intention to agree a structure and
process required for Fujitsu Services to establish a Fujitsu Services-led agile software
delivery capability (the “Digital Development Services” or “DDS’), including:
1.1.1. the contractual mechanism for incorporating the new delivery capability into
the Agreement;
1.1.2 the financial charging mechanism;
1.1.3 the roles, responsibilities and dependencies required for Fujitsu Services to
lead the agile teams;
1.1.4 the size and scope of the teams; and
1.1.5. the mechanisms and processes required to manage the developments.
1.2 Accordingly this Schedule 13 (Digital Development Services) sets out the structure
and process by which Fujitsu Services shall provide, and the Post Office shall
consume, Digital Development Services.
1.3 For clarity where the parties agree to use the DDS in order to develop Software the
provisions relating to Development Services within Schedule B1.1 (Development
Services) shall not apply.
1.4 The provision of this Schedule 13 shall apply until 31st March 2023, after which the
Digital Development Services shall expire.
Schedule I3 Version 15.0
Page 1 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
2. DEFINITIONS
The following terms shall have the corresponding meanings for the purposes of this
Schedule 13 (Digital Development Services):
Acceptance means, in respect of any Sprint Requirement, that the Sprint
Functionality meets: (i) its Acceptance Criteria; and (ii) the relevant Definition of Done
in accordance with the provisions of paragraph 1.25 of Appendix 1 (Agile
Methodology), and “Accepted” shall be construed accordingly;
Acceptance Criteria means, in respect of any Sprint Requirement, the acceptance
criteria that shall be applied to the relevant Sprint Functionality;
Acceptance Tests means, in respect of any Sprint Requirement, the tests to be run
to determine whether the relevant Sprint Functionality complies with the relevant
Acceptance Criteria and the expected results of those tests;
Agile Methodology means the processes and standards set out in or referred to by
paragraph 9;
Agreed Metrics means the metrics referred to in Part 2 of Appendix 4 (Governance);
Business Case means, in respect of each Product, a document created by Post
Office in accordance with its internal processes and requirements that builds upon
the Product Vision and, amongst other things, sets out the expected: (i) investment
required for creating the Product; (ii) tangible and intangible benefits; and (iii) financial
return on investment;
Collaboration Technology means compatible audio and video conferencing
facilities between the Post Office and Fujitsu Services with the ability to share
screens;
Daily Stand Up means a meeting of the Sprint Team on each Business Day during
the DDS Term (except during any period of leave agreed by the parties) to discuss:
(i) tasks completed on the previous Business Day; (ii) tasks to be completed on the
current Business Day; and (iii) any impediments potentially affecting attainment of the
Sprint Requirements;
DDS Commencement Date means 1 August 2018;
DDS Rate Card means the rate card set out in Appendix 5 (DDS Charges);
DDS Service Review means the meeting described under the heading DDS Service
Review in Part 1 of Appendix 4 (Governance);
DDS Term means the period of time from the DDS Commencement Date until 31
March 2023;
DDS Tools means the tools listed in Appendix 6 (Too/s), together with any other tools
required for delivery of the DDS as agreed between the parties and specified in the
Product Overview Document;
Definition of Done means, in respect of any Sprint Requirement, the criteria set out
in Appendix 2 (Definition of Done) as well as any additional specific criteria agreed
Schedule I3 Version 15.0
Page 2 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
by the parties that must be successfully met for the specific Sprint Functionality to be
considered complete;
Definition of Ready has the meaning given in paragraph 1.11 of Appendix 1 (Agile
Methodology);
Delivered Sprint Requirement means a Sprint Requirement that is Accepted;
Demand Forecast means the overall forecast of demand for the Digital Development
Services, including details of all Products within scope of DDS;
Digital Demand Forecasting Board means the meeting described under the
heading Digital Demand Forecasting Board in Part 1 of Appendix 4 (Governance);
Disrupted Sprint has the meaning given in paragraph 11.4;
Estimating Methodology means the agile methodology used for the purposes of
sizing User Stories and allocating an appropriate number of Story Points, as agreed
between the parties;
MOU means the memorandum of understanding between Post Office and Fujitsu
Services dated 16 November 2017;
Participants means those persons referred to in Appendix 3;
Per Sprint Story Point Allocation means one hundred (100) Story Points;
Platform Standing Team has the meaning given in paragraph 3.5;
Post Office DDS Locations means the UK offices where any element of the DDS is
performed by Fujitsu Services, being: (i) 3rd Floor, 100 Wood Street, London EC2V 7ER.
and (ii) 4 Middle Pavement, The Pavements, Chesterfield, S40 1PA;
Product means a software solution, or collection of software solutions with its own
Product Backlog, managed independently of any other Product;
Product Backlog has the meaning given in paragraph 1.7 of Appendix 1 (Agile
Methodology),
Product Initiation means the process by which the Product Delivery Manager and
the Product Owner agree the Product Overview Document;
Product Roadmap means the document created per Product which sets out the
roadmap for the Product including the Product Vision and the Release Plan and is
updated by the Product Delivery Manager regularly;
Product Delivery Manager has the meaning given in paragraph 5.4;
Product Overview Document means the summary of the Product Vision, the
architecture approach, the Release and Test Strategy, the intended service model
and the initial release roadmap for each Product;
Product Owner has the meaning given in paragraph 5.2;
Product Sponsor has the meaning given in paragraph 5.3;
Product Vision means a document created by Post Office as an outline of the
Product, describing its goals, targeted benefits and overall focus;
Schedule I3 Version 15.0
Page 3 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
Reference User Stories means the library of reference User Stories maintained by
Fujitsu Services and reviewed, and where necessary updated, quarterly, containing
example User Stories that have been sized and allocated a number of Story Points
in accordance with the Estimating Methodology, with each such User Story also
including narrative and description so as to set out the justification for the applicable
number of Story Points that were allocated and, following the applicable Sprint, the
number of Story Points actually required to complete such User Story;
Release means a collection of Delivered Sprint Requirements that have been
approved by the Product Owner for release into the live environment in accordance
with the Release and Test Strategy;
Release and Test Strategy means a document created by Post Office that sets out
the approach to testing and release for the particular Product in accordance with
Paragraph 8;
Release Plan means the planned schedule of releases for the Product to the live
environment;
Relief Event means a failure by Post Office to satisfy the relevant Sprint
Dependencies or Transition Dependencies;
Service Requirement means the document describing the nature and level of in-life
support that the Product will require once accepted into production within the Post
Office environment;
Software means the software to be developed under this Schedule I3 (Digital
Development Services);
Source Code means the source code of the Software to which it relates, in the
language in which the software was written, together with all related flowcharts and
technical documents, all of a level sufficient to enable the Post Office’s development
personnel to understand, develop and maintain that Software;
Sprint means a development cycle performed as part of the DDS;
Sprint Backlog has the meaning given in paragraph 1.13.1 of Appendix 1 (Agile
Methodology);
Sprint Closure Report means, in respect of each Sprint, the report to be created as
an output of the Sprint Retrospective Meeting which sets out the number of User
Stories completed in each Sprint as against the number of User Stories which were
proposed to be completed within the same Sprint, details of any Relief Events, and
any known reasons where the number of achieved User Stories is less than the
number of proposed User Stories in the same Sprint;
Sprint Dependencies means the dependencies listed in paragraph 12 and, in
respect of any specific Sprint, the dependencies agreed between the Product Owner
and the Product Delivery Manager prior to the commencement of such Sprint in
accordance with paragraph 1.14 of Appendix 1 (Agile Methodology);
Sprint Functionality has the meaning given in paragraph 1.19 of Appendix 1 (Agile
Methodology);
Schedule I3 Version 15.0
Page 4 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
3.1
3.2
3.3
3.4
Sprint Planning Meeting has the meaning given in paragraph 1.13 of Appendix 1
(Agile Methodology);
Sprint Requirement has the meaning given in paragraph 1.13.7 of Appendix 1 (Agile
Methodology);
Sprint Retrospective Meeting has the meaning given in paragraph 1.27 of Appendix
1 (Agile Methodology);
Sprint Review Meeting has the meaning given in paragraph 1.23 of Appendix 1
(Agile Methodology);
Sprint Team means the Participants in the Sprint (as described in paragraph 6.1)
and any replacements from time to time;
Standard Sprint Team Structure has the meaning given in paragraph 6.1;
Story Points means a unit of measurement of the effort required for completion of
each User Story to be estimated by the Sprint Team in accordance with the principles
in paragraphs 1.7 and 1.17 of Appendix 1 (Agile Methodology);
Transition Dependencies means any Post Office dependencies upon which the
successful completion of the transition activities set out within CT 2609 are
dependent, as explicitly identified within the CT 2609 as Post Office Dependencies;
Transition Period means the period of transition as set out in the CT 2609; and
User Story means a non-technical description of a development requirement of Post
Office, expressed as a high level outcome, including the intended operations,
functions, performance, non-functional requirements, service requirements and other
characteristics of the Software or part of the Software.
STRUCTURE OF THE SERVICE
The Oversight Roles
Each party will provide the oversight roles detailed in paragraph 4 to enable delivery
and operation of the DDS in accordance with this Schedule 13.
Where any of Fujitsu Services appointed oversight roles are agreed by the parties to
be provided from the Core Team, Fujitsu Services agrees that, notwithstanding
paragraph 14.2 of Annex 3 of Schedule A2 to the Agreement, Post Office shall not
be required to give three (3) months’ notice to Fujitsu Services in order to effect this
variation of the posts in the Core Team.
The Charges for the Fujitsu Services appointed oversight roles are detailed in
Appendix 5 (DDS Charges).
Product Roles
The Product Roles provide services to support individual Products which sit outside
of the Sprint Team structure, as more fully described in Appendix 3. The “Product
Roles’ will be made up of the following Participants and will, unless otherwise agreed
during Product Initiation or subsequently during an annual review of the same for
Schedule I3 Version 15.0
Page 5 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
3.5
3.6
3.7
3.8
3.9
3.10
4.1
4.2
4.3
each Product by the parties, require one of each of the following Participants per
Product:
3.4.1. Product Sponsor (Post Office role);
3.4.2 Product Owner (Post Office role);
3.4.3 UX designer (Post Office role);
3.4.4 Product Delivery Manager (Fujitsu Services role); and
3.4.5 Solution Owner (Fujitsu Services role);
who shall have the responsibilities set out in Appendix 3 (Participants).
The Platform Standing Team
Fujitsu Services shall provide a “Platform Standing Team”, which shall provide an
overarching capability to manage the delivery of the DDS and shall provide the
following functions:
3.5.1 platform engineering;
3.5.2 environment and configuration engineering;
3.5.3 CI/CD automation engineering;
3.5.4 security engineering;
3.5.5 test automation engineering;
3.5.6 performance and availability engineering.
The Charges for the Platform Standing Team are detailed in Appendix 5 (DDS
Charges).
Sprint Teams
Sprint Teams shall be responsible for delivering Software that provides functionality
to fulfil User Stories under the DDS.
The make-up of a standard Sprint Team is detailed in paragraph 4 below.
Sprint Teams shall be ordered by Post Office in accordance with the process set forth
within Appendix 5 (DDS Charges).
The Charges for a standard Sprint Team are detailed in Appendix 5 (DDS Charges).
PARTICIPANTS AND THEIR RESPECTIVE ROLES
Post Office oversight roles
Post Office shall appoint a “Delivery Lead”. The Delivery Lead shall have the
responsibilities set out in Appendix 3 (Participants).
Post Office shall appoint a “Test Manager’. The Test Manager shall have the
responsibilities set out in Appendix 3 (Participants).
Post Office shall utilise its existing release management process to carry out the
activities assigned to the Post Office obligation to provide a release manager, the
responsibilities for which are set out in Appendix 3 (Participants).
Schedule I3 Version 15.0
Page 6 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
Fujitsu Services oversight roles
4.4 Fujitsu Services shall appoint a “DDS Lead”. The DDS Lead shall have the
responsibilities set out in Appendix 3 (Participants).
4.5 Fujitsu Services shall appoint an “Architect Owner”. The Architect Owner shall have
the responsibilities set out in Appendix 3 (Participants).
4.6 Fujitsu Services shall appoint a “Release Coordinator’. The Release Coordinator
shall have the responsibilities set out in Appendix 3 (Participants).
47 The parties may agree jointly to appoint an agile coach and where this is the case
the parties shall fund this resource between them with the precise allocation to be
agreed but based on the principle that both parties must derive benefit from this role
for both parties to share the resource costs.
Location
4.8 Post Office agrees that the individuals fulfilling the Standard Sprint Team roles may
be based in different locations, which may be geographically dispersed including
outside the UK, provided that Fujitsu Services:
4.8.1 where individuals are working within Fujitsu Services controlled premises,
provides the Sprint Team with Collaboration Technology that ensures that
individuals are able to work efficiently and effectively across such locations;
and
4.8.2 ensures that there is no compromise in quality of the Digital Development
Services where roles in the Sprint Team fulfilled by members of Fujitsu
Services personnel are delivering Digital Development Services from
outside the United Kingdom, and ensures that Post Office has access to
such members of Fujitsu Services personnel, including the ability to visit
them at the relevant Fujitsu Services premises, provided that reasonable
notice is provided by to Fujitsu Services by Post Office.
4.9 Where individuals are working within Post Office controlled premises, Post Office
shall provide the Sprint Team with Collaboration Technology that ensures that
individuals are able to work efficiently and effectively across such locations.
5. KEY PERSONNEL
5.1 The parties agree that the following roles shall be Key Personnel for the purposes of
Clause 41 of the Agreement:
5.1.1. Product Delivery Manager;
5.1.2 DDS Lead; and
5.1.3 Architect Owner.
6. SPRINT TEAM STRUCTURE
6.1 The following shall be the standard structure for a Sprint Team (“Standard Sprint
Team Structure’):
Schedule I3 Version 15.0
Page 7 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
6.2
6.3
6.4
6.1.1 1 ScrumMaster;
6.1.2 4 Developers;
6.1.3 1 Tech Lead;
6.1.4 2 Test Analysts; and
6.1.5 1 Business Analyst,
each of which shall have the responsibilities set out within Appendix 3 (Participants).
The parties acknowledge and agree the benefit of standardisation and consistency in
the structure and delivery of the Digital Development Services. However, during the
Product Initiation phase or at any other time agreed by the Digital Demand
Forecasting Board (on at least 90 days’ prior notice), if, despite having acted
reasonably to seek to use the Standard Sprint Team Structure and standard size of
Sprint Team, Post Office and Fujitsu Services are unable to make use of such
Standard Sprint Team Structure, Post Office and Fujitsu Services may agree (or, in
exceptional circumstances only, where the Standard Sprint Team Structure and
standard size of Sprint Team cannot accommodate the Sprints intended for a Sprint
Team, Post Office may require):
6.2.1 analternative structure for a Sprint Team for a given Product that differs from
the Standard Sprint Team Structure in which case the parties will agree upon
the allocated roles to be contained within that alternative or smaller Sprint
Team and consider any applicable necessary changes to the Per Sprint
Story Point Allocation accordingly, taking into consideration the composition
of the Sprint Team and increased (for example, due to improved
communication as a result of a smaller team) or decreased (for example, a
larger percentage of a smaller team providing management, rather than
development, functions) efficiencies introduced through the size of Sprint
Team;
6.2.2 an alternative, smaller size for a Sprint Team, in which case the parties will
agree upon the allocated roles to be contained within that alternative or
smaller Sprint Team and consider any applicable necessary changes to the
Per Sprint Story Point Allocation accordingly; or
6.2.3 to fill a Fujitsu Services appointed role in the given Sprint Team with a Post
Office individual (provided that the ScrumMaster and Tech Lead shall always
be filled by Fujitsu Services).
For clarity, the day to day management of the Sprint Team resides with Fujitsu
Services and Post Office shall ensure that any of the Sprint Participants who are Post
Office roles agree to accept management and direction by Fujitsu Services.
For each Sprint, Fujitsu Services shall ensure that the Fujitsu Services appointed
roles in the Standard Sprint Team Structure are filled by effectively trained individuals
with the abilities, qualifications and experience necessary to meet the Sprint
Requirements. The parties acknowledge the continuity benefit of retaining the same
individuals in the appointed roles and therefore any changes will need to be managed
to minimise Sprint disruption. In particular, Fujitsu Services shall not change any
Schedule I3 Version 15.0
Page 8 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
7.1
7.2
7.3
8.2
individual in the Fujitsu Services appointed roles without a valid, justifiable reason for
doing so, which it shall provide to Post Office in advance of the individual being
changed. Where the Sprint Requirements for a Sprint require particular skillsets,
Fujitsu Services may, in consultation with the Product Owner, vary the individuals in
the Fujitsu Services appointed roles for that Sprint in order to match such skillsets.
DEMAND FORECASTING
The Digital Demand Forecasting Board
Post Office shall be responsible for arranging and managing the Digital Demand
Forecasting Board which shall meet every 12 weeks during the DDS Term, and as
otherwise required. The Digital Demand Forecasting Board shall work with the Post
Office’s portfolio management processes to understand, assess and manage the
overall Demand Forecast. Should the Digital Demand Forecasting Board fail to meet
as scheduled, Fujitsu Services shall escalate the same to Post Office’s Group ClO
as a priority and the Digital Demand Forecasting Board shall urgently meet within 5
business days of such escalation.
The Digital Demand Forecasting Board shall be responsible for:
7.2.1 reviewing and registering new Products on the Demand Forecast by
assessing whether there is available capacity for these within the current
resources involved in the provision of DDS (as set out in Appendix 3);
7.2.2 agreeing the Sprint Team requirements and associated increase or
decrease in other resources as appropriate on a 90 day ordering block as
more fully described in Appendix 5;
7.2.3 shifting available capacity from one Product to another Product as forecast
demand flexes (including where Post Office requires urgent works on a
Product or otherwise wishes to prioritise or expedite a Product); and
7.2.4 allocating Sprint Teams to Product Owners and Product Delivery Managers/
The commercial mechanisms for ordering additional capacity or reducing a previous
commitment are set out in Appendix 5 to this Schedule 13.
The provisional attendees to the Digital Demand Forecasting Board are set out in
Appendix 4 (Governance).
PRODUCT INITIATION
Once the Product Vision and Business Case have been produced by the relevant
Product Sponsor and approved internally by Post Office, then where Post Office
requires Fujitsu Services to commence the delivery of the relevant Product it shall
commence Product Initiation. Product Initiation utilises the Product Vision and
Business Case to deliver the pre-requisites and dependencies that are necessary
before development work can commence.
As part of Product Initiation, Fujitsu Services, with Post Office input, shall produce the
following key deliverables:
Schedule I3 Version 15.0
Page 9 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
8.3
10.
11.
8.2.1 a Product Overview Document, which will contain the following components,
some of which will have been prepared by Post Office:
(a) a detailed Product Vision which has been prepared by the Product
Owner;
(b) an overview of the architectural approach, including an agreement
as to any elements of the Product which are Listed Rights (if known
at this stage);
(c) a Release and Test Strategy for the Product which itself has been
prepared by the Post Office; and
(d) the Service Requirements for supporting the Product once live; and
8.2.2 an initial Product Backlog.
In order to support Post Office to complete the Product Roadmap for the Product,
Fujitsu Services will perform the following activities:
8.3.1 provide support and expertise to the Product Owner to enable effective
planning;
8.3.2 analyse User Stories to provide advice on dependencies and pre-requisites
so that User Stories in the Product Backlog can be correctly prioritised and
sequenced;
8.3.3 provide advice on the size and complexity of each User Story to enable items
in the Product Backlog to be scheduled into available Sprints;
8.3.4 provide input to enable Product Backlog items to be identified as Planned
User Stories and/or Stretch User Stories; and
8.3.5 feed into the Digital Demand Forecasting board as necessary.
AGILE METHODOLOGY
Each party shall act in accordance with the provisions of Appendix 1 (Agile
Methodology).
PERFORMANCE METRICS
The parties shall comply with the terms of Appendix 4 (Governance) and Appendix 8
(Service Credit Mechanism).
RELIEF EVENTS AND DISRUPTED SPRINTS
To the extent that Fujitsu Services becomes aware that it may be unable to complete
a Sprint Requirement as the result of the occurrence of a Relief Event, Fujitsu shall:
11.1.1 notify Post Office as soon as reasonably possible and at the next Daily
Stand-up; and
11.1.2 use its reasonable endeavours to mitigate the Relief Event (which may
include working on alternative User Stories within the Sprint Backlog).
Schedule I3 Version 15.0
Page 10 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
11.2 Where Fujitsu Services is not able to sufficiently mitigate the Relief Event, the
affected Sprint Requirement(s) shall be removed from the relevant Sprint and the
matter shall be escalated to the ScrumMaster and Product Owner, who shall refer the
matter (with their recommendations) to the Delivery Lead and Product Delivery
Manager for resolution. The parties will agree the impact of the Relief Event on the
affected Sprint Requirement(s) upon the Sprint (including with regard to Appendix 8
(Service Credit Mechanism)).
11.3 Fujitsu Services shall not be liable for failing to complete a Sprint Requirement that
has been removed from a Sprint pursuant to paragraph 11.2, but shall still be required
to seek to complete the remainder of the Sprint Requirements in the relevant Sprint.
11.4 Where the Product Owner elects in respect of any given Sprint to cease such Sprint
or to make a material change to a Sprint prior to scheduled completion, and such
Sprint is thus ceased prior to scheduled completion, such Sprint shall be considered
a “Disrupted Sprint”.
11.5 Where a Priority 1 or Priority 2 incident occurs in respect of a given Product (as
determined by Post Office) and such incident is identified through the existing incident
management procedures as being within the remit of the Digital Development Service
as a resolver group, then (unless otherwise specified by Post Office), one or more of
the Sprint Teams for such Product (as directed by the DDS Lead) shall immediately
prioritise resolving such incident, irrespective of the current Sprint Backlog. The
occurrence of such Priority 1 or Priority 2 incident shall be considered a Relief Event
for the impacted Sprints.
12. CHARGES
12.1 In consideration for the provision of the Digital Development Services, Post Office
shall pay to Fujitsu Services the Charges set out in Appendix 5 (DDS Charges) (the
“DDS Charges’).
13. DEPENDENCIES
13.1 The following Post Office Dependencies shall apply to all Sprints:
13.1.1. Post Office shall provide Collaboration Technology in accordance with
paragraph 4.9 together with appropriate workspace for agile development at
the Post Office Locations;
13.1.2 Post Office shall obtain and shall maintain and adhere to the terms of all
necessary licences, consents, and permissions necessary for Fujitsu
Services, the Sprint Teams and the ScrumMaster to perform their respective
roles, responsibilities, obligations and duties under this agreement, provided
that Fujitsu Services have previously notified Post Office of these licences,
consents and permissions together with the relevant requirements;
13.1.3 Post Office shall ensure that all network connections and
telecommunications links reasonably required by Fujitsu Services in order to
provide the Digital Development Services comply with the relevant
specifications provided by Fujitsu Services from time to time;
Schedule I3 Version 15.0
Page 11 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
13.1.4 For each Sprint, Post Office shall ensure that the Post Office appointed roles
in the Standard Sprint Team Structure are filled by effectively trained
individuals with the abilities, qualifications and experience reasonably
necessary to perform their respective obligations; and
13.1.5 Post Office shall provide the necessary development and test environments
needed for the parties to develop, test and implement the Software created
pursuant to the Digital Development Services.
14. LIABILITY
14.1 Notwithstanding Clause 44, the total aggregate liability of Fujitsu Services, whether
in contract, tort (including negligence) or otherwise for all Defaults arising under or in
connection with the Digital Development Services (including this Schedule 13), in any
given Financial Year, shall in no circumstances exceed the greater of (i) the Charges
for Digital Development Services paid or payable in or in respect of such Financial
Year; and (ii) £7,200,000 from 1st April 2018 until 31st March 2020 and £4,358,400
from 1st April 2020 to 31st March 2023.
Schedule I3 Version 15.0
Page 12 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
APPENDIX 1
AGILE METHODOLOGY
1. GENERAL
1.1 The Participants shall adopt an agile development methodology based upon the
“Scrum Framework” for the Products in the Product Roadmap and development work
shall be carried out during a series of Sprints and in accordance with the processes
set out within this Appendix 1 (Agile Methodology).
1.2 Each Sprint shall have a fixed period of two (2) weeks, during which a Sprint Team
shall complete and test Sprint Functionality in respect of all Sprint Requirements in
the Sprint Backlog. On the completion of a Sprint, the Sprint Team shall promptly
commence the next Sprint for which a Sprint Backlog has been prepared in
accordance with paragraphs 1.17 of this Appendix 1 (Agile Methodology).
1.3 The Participants shall use the DDS Tools in the provision of the DDS.
1.4 The total number of Story Points for the User Stories allocated to each Sprint shall
equal the Per Sprint Story Point Allocation for all Standard Sprint Teams. For the
avoidance of doubt, the Sprint Backlog for each Sprint will include additional User
Stories in excess of the Per Sprint Story Point Allocation, which may be used by the
Sprint Team in place of those User Stories due to be completed during such Sprint
where required to enable Fujitsu Services to manage the throughput and achieve the
Per Sprint Story Point Allocation. An example of when this might occur is an
unexpected inability to complete a given User Story during such Sprint.
1.5 Notwithstanding any other provision of this Agreement the parties acknowledge that
the goal of each Sprint is to complete Sprint Functionality to fulfil all Sprint
Requirements within the applicable Sprint Backlog; however, by nature of the agile
approach used in the delivery of the Digital Development Services, it may be the case
that, despite the Sprint Team having completed sufficient Story Points so as to meet
the Per Sprint Story Point Allocation for the applicable Sprint, not all such Sprint
Functionality is completed within such Sprint. Accordingly, for the purposes of the
Service Levels, Fujitsu Services’ performance under this DDS Schedule shall be
assessed against the number of Story Points actually completed and delivered within
each Sprint, rather than the number of Sprint Requirements fulfilled. For the
avoidance of doubt, where the estimated Story Points for a Sprint Requirement
changes during the course of a Sprint then, where agreed between the parties, the
actual Story Point allocation for that Sprint Requirement will be considered for the
purposes of assessing Fujitsu Services pursuant to Appendix 8 (Service Credit
Mechanism).
1.6 Sprints may be run in parallel, where conducted by separate Sprint Teams.
Product Backlog
1.7 A product backlog shall be prepared for each Product by the relevant Product Owner,
using the Product Backlog tool and in consultation with the Product Delivery Manager,
and shall include the following items:
Schedule I3 Appendix 1 Version 15.0
Page 13 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
1.8
1.9
1.7.1 aprioritised set of development requirements (which may include bug fixes,
minor enhancements, new feature requests, non-functional requirements,
service requirements and major functionality changes) to be completed,
expressed as User Stories;
1.7.2 the estimated business value of each User Story;
1.7.3 anestimate of the number of Story Points for each User Story, allocated with
reference to the Reference User Stories;
1.7.4 aset of Acceptance Criteria for each User Story and any further details of
these User Stories provided by the Product Owner; and
1.7.5 a Definition of Done for all User Stories,
(the “Product Backlog’).
The Product Owner may add User Stories to the relevant Product Backlog at any time
and, when any such User Story is added, the Product Delivery Manager shall, in
consultation with the Product Owner, set the number of Story Points using the
Estimating Methodology and with reference to the Reference User Stories and the
Acceptance Criteria.
A Product shall be complete once all User Stories in the Product Backlog have been
delivered and the Product Owner has notified Fujitsu Services accordingly.
Notwithstanding the foregoing, the Product Owner may opt to end the delivery of the
Product at any point prior to the completion of all User Stories.
For the avoidance of doubt, the Product Backlog may include third line support
activities arising as a result of incidents and problems raised by Post Office and
triaged for resolution to the Digital Development Service through the existing incident
management procedures.
User Stories and the Definition of Ready
Before User Stories from the relevant Product Backlog can be included in a Sprint,
they shall meet the following requirements:
1.11.1 User Stories should be written in this format “As a <kind of user> I want
<feature> so that <benefit>” and satisfy the criteria of the INVEST matrix;
1.11.2 User Stories shall each include all appropriate investment criteria and
Acceptance Criteria both of which are written in a way that can be
understood by the Sprint Team;
1.11.3 User Stories shall be written in a way that can be understood by the Sprint
Team, especially the developers and testers;
1.11.4 User Stories shall include both functional and non-functional requirements;
1.11.5 User Stories shall have an associated level of priority;
1.11.6 User Stories shall have unique identifiers to maintain traceability and to ease
the mapping of User Stories where User Stories are related;
Schedule I3 Appendix 1 Version 15.0
Page 14 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
1.11.7 User Stories have been sized and allocated a number of Story Points using
the Estimating Methodology by the Sprint Team (and confirmed by the
Product Delivery Manager) and utilising the Reference User Stories; and
1.11.8 the Sprint Team understands how the User Story will be tested and
demonstrated,
(together the “Definition of Ready’).
The Sprint Team, working with the Product Delivery Manager and the Product Owner,
shall be entitled to reject any User Stories that do not meet the Definition of Ready at
least 10 business days prior to the proposed Sprint. Where a User Story is rejected
pursuant to this paragraph 1.12 of Appendix 1 (Agile Methodology), the Product
Delivery Manager and the Product Owner may agree to return the User Story to the
Product Backlog to be rewritten and included in a later Sprint.
Sprint Planning Meeting
The Participants shall hold a sprint planning meeting at least 5 business days before
each Sprint commences (the “Sprint Planning Meeting”). At the Sprint Planning
Meeting:
1.13.1. the Product Owner shall identify which User Stories from the relevant
Product Backlog he/she wishes to be included in the backlog for such Sprint
(the “Sprint Backlog”);
1.13.2 the Sprint Team, working with the Product Delivery Manager and the Product
Owner, shall agree the nature of any accompanying documentation required
for each User Story within the Sprint Backlog;
1.13.3 the Sprint Team, working with the Product Delivery Manager and the Product
Owner, shall review and confirm and/or refine the estimated number of Story
Points for each User Story within the Sprint Backlog;
1.13.4 the Sprint Team, working with the Product Delivery Manager and the Product
Owner, shall review and confirm and/or refine the Acceptance Criteria for
each User Story within the Sprint Backlog, specify the Acceptance Tests and
review and confirm and/or refine the Definition of Done that will apply to
every User Story within the Sprint Backlog. As a minimum, the Definition of
Done shall include the criteria set out in Appendix 2 (Definition of Done);
1.13.5 based on the output of the processes in paragraphs 1.13.3 and 1.13.4 of this
Appendix 1 (Agile Methodology), the Sprint Team, working with the Product
Delivery Manager and the Product Owner, shall determine how many of
such User Stories can be completed during such Sprint, provided that the
sum of the Story Points for the User Stories shall equal the Per Sprint Story
Point Allocation;
1.13.6 the Sprint Team, working with the Product Delivery Manager and the Product
Owner, may decide to replace a higher priority User Story with a lower
priority User Story bearing equal or fewer Story Points if it is technically
expedient to do so; and
Schedule I3 Appendix 1 Version 15.0
Page 15 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
1.13.7 the Product Delivery Manager and the Product Owner shall agree the final
selection of User Stories to be included in the Sprint Backlog (each, a “Sprint
Requirement’).
1.14 At the Sprint planning meeting, the Product Delivery Manager and the Product Owner
will also identify and agree the specific Sprint Dependencies on Post Office that are
required for the Sprint Team to be able to complete the Sprint Requirements.
1.15 At the Sprint Planning Meeting, the Product Delivery Manager and the Product Owner
will also review and confirm and/or refine which (if any) elements of the Sprint
Functionality will be Listed Rights in accordance with Paragraph 7 of Schedule H
(Digital Intellectual Property Provisions).
1.16 Once the Sprint Requirements for a Sprint have been agreed, no alterations or
additions to the Sprint Requirements (including the estimated number of Story Points,
Definition of Done and Acceptance Criteria) shall be made.
Sprint Backlog
1.17 The Product Delivery Manager shall then prepare the Sprint Backlog in consultation
with the Product Owner, which shall include:
1.17.1 the agreed Sprint Requirements;
1.17.2 the agreed number of Story Points allocated to each Sprint Requirement;
1.17.3 a breakdown of each Sprint Requirement into specific tasks and allocation
to individuals within the Sprint Team;
1.17.4 the Acceptance Criteria for each Sprint Requirement and the Definition of
Done for every Sprint Requirement; and
1.17.5 the agreed Sprint Dependencies.
1.18 The Sprint Backlog shall be completed no later than 10 business days prior to the
start of the applicable Sprint and, unless otherwise agreed by the parties, will contain
at least 120 Story Points worth of User Stories.
Sprints
1.19 During each Sprint, the Sprint Team shall develop the functionality to meet each
Sprint Requirement in accordance with the Sprint Backlog, any agreed coding
standards and this Schedule 13 (Digital Development Services) (the “Sprint
Functionality”).
1.20 By the end of each business day during the course of each Sprint, the Sprint Team
shall ensure that all functionality and other materials developed during the course of
such business day are made available (in their current state of development) in
Source Code form on an agreed code repository, for review by Post Office. The
Sprint Team shall consider, and where appropriate implement, any feedback from
such review during the course of the Sprint provided that any change to a User Story
during the Sprint may only proceed with the express consent of both the Product
Delivery Manager and Product Owner.
Schedule I3 Appendix 1 Version 15.0
Page 16 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
1.21
1.22
1.23
1.24
1.25
1.26
During each Sprint, the Sprint Team shall maintain the Sprint Backlog and update it
daily to reflect progress towards completion of the Sprint Requirements.
If, during the course of any Sprint, a dispute between the Parties arises in connection
with any Sprint Requirement which cannot be resolved within the Sprint Team, then
such Sprint Requirement shall be immediately removed from the scope of such Sprint
and the Sprint Team will seek to deliver an alternative User Story from the Sprint
Backlog to make up the Per Sprint Story Point Allocation. Where there is no
alternative User Story that is reasonably suitable to be delivered during the Sprint in
place of such Sprint Requirement, then for the purposes of assessing performance
under Appendix 8 (Service Credit Mechanism), the Per Sprint Story Point Allocation
for that Sprint shall be reduced by the number of Story Points allocated to the
removed Sprint Requirement and all Story Points expended on such Sprint
Requirement during the Sprint shall be excluded from any Service Level calculation.
Sprint Review Meetings
Within 5 business days of the last day of each Sprint, the Product Delivery Manager,
the Product Owner and the Sprint Team shall hold a review meeting in respect of
such Sprint (a “Sprint Review Meeting”). At the Sprint Review Meeting, the
Participants shall:
1.23.1 determine whether the Sprint Functionality meets the Acceptance Criteria
for each Sprint Requirement, and the Definition of Done for all Sprint
Requirements, in the Sprint;
1.23.2 agree the manner in which any ongoing support for the Sprint Functionality
will be handled; and
1.23.3 review the Agreed Metrics for the Sprint and, where appropriate, propose
additional measures to be added to the Agreed Metrics for consideration by
the DDS Service Review.
Any Sprint Requirement the Sprint Functionality for which has: (i) not met its
Acceptance Criteria; (ii) not met the relevant Definition of Done; or (iii) not been
developed during the relevant Sprint, shall not be submitted to Post Office for
Acceptance.
Any Sprint Requirement the Sprint Functionality for which has: (i) met its Acceptance
Criteria; and (ii) met the relevant Definition of Done, shall be submitted to Post Office,
in both source and object code form for Acceptance. Within 2 business days of such
submission, the Product Owner shall sign such report to indicate agreement as to
that Sprint Functionality that has been Accepted. Where the Product Owner has not
signed the acceptance report or demonstrated why any Sprint Functionality has not
met the Definition of Done and the Acceptance Criteria in accordance with the above
timescales, Fujitsu Services shall escalate the matter to the Post Office Delivery Lead
who shall use all reasonable endeavours to provide a signed form of acceptance, or
provide reasonable evidence of why any Sprint Functionality has not been Accepted,
within 24 hours of the escalation.
Where Sprint Functionality is:
Schedule I3 Appendix 1 Version 15.0
Page 17 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
1.26.1 Accepted, it shall be marked as complete in the Sprint Backlog and the
relevant Product Backlog; or
1.26.2 not Accepted, it shall not be marked as complete in the Sprint Backlog and
the relevant Product Backlog, and the Product Owner shall reset the priority
for each outstanding User Story in the relevant Product Backlog.
Sprint Retrospective Meetings
1.27 Within 5 business days of the end of each Sprint, the ScrumMaster, the Delivery
Lead, the Product Delivery Manager and the Product Owner shall also hold a
retrospective meeting in respect of such Sprint (a “Sprint Retrospective Meeting’).
At the Sprint Retrospective Meeting, the Participants shall:
1.27.1 assess the impact of any Disrupted Sprints and/or Relief Event(s) on that
Sprint; and
1.27.2 discuss and agree potential improvements to their practices, teamwork and
environment for implementation in subsequent Sprints.
1.28 Prior to the Sprint Retrospective Meeting, the ScrumMaster shall provide all reports
specified in Part 2 of Appendix 4 (Governance) to Post Office.
Schedule I3 Appendix 1 Version 15.0
Page 18 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
APPENDIX 2
DEFINITION OF DONE
1. THE DEFINITION OF DONE:
1.1 The Definition of Done shall comprise the following criteria:
1.1.1. the Acceptance Criteria applicable to the Sprint Requirement are met;
1.1.2 all code is peer reviewed, compiled and checked into the agreed code
repository;
1.1.3 all: (i) code is tested — code comes with automated tests — unit and
functional, which have passed successfully (as evidenced by relevant
automated test reports); (ii) unit tests are in Post Office’s designated
development code repository; (iii) manual test scripts are in an appropriate
test script management tool; and (iv) automated test scripts checked into a
suitable test repository;
1.1.4 all code builds without error and is integrated onto the agreed continuous
integration tooling;
1.1.5 the build is deployed to a demo server;
1.1.6 the relevant User Story is updated; and
1.1.7 all agreed documentation has been produced and meets its Acceptance
Criteria.
Schedule I3 Appendix 2 Version 15.0
Page 19 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
APPENDIX 3
DDS PARTICIPANTS
1. GENERAL
1.1 During the Transition Period, the parties shall review the contents of this Appendix 3
(DDS Participants) and shall agree any required updates together with specific
responsibilities for each role set out herein.
2. ORGANISATION
RSI BRS Bane eae
nia
Platform Standing Team,
Release Goordnator ]
3. PLATFORM STANDING TEAM
3.1 Scope and Purpose
3.1.1
The Platform Standing Team provide services to support the DDS using a
DevOps model. This includes the provisioning, support and maintenance of
environments for development, test and validation purposes, the support,
operation and maintenance of tooling to support development, test and
validation, and the provision of continuous build and integration automation
to ensure that developed code can be promoted through each environment
and into the live estate.
3.2 Platform Engineering
A function that:
3.2.1
3.2.2
3.2.3
3.2.4
Works to identify, plan and monitor demand for DDS
Prioritises activities to support the smooth running of DDS
Maintains, tracks and owns activities and tasks using agile methods to
ensure work in progress is minimised and cycle time for activities is
optimised
Contributes to, and reviews architectural designs and decisions with expert
advice on platform design
Schedule I3 Appendix 3 Version 15.0
Page 20 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
3.2.5 Identifies and develops platform solutions to ensure high availability
3.2.6 — Identifies, designs and develops mechanisms and solutions that support and
enable zero-downtime deployment
3.2.7 Identifies, designs and develops resource monitoring utilities to identify and
prevent performance and availability incidents
3.2.8 Identifies, designs and develops performance and capacity testing solutions
3.2.9 Monitors and evaluates resource consumption;
3.2.10 Supports, guides and coaches team members;
3.2.11 Acts as a point of contact for platform related matters
3.3 Environment and Configuration Engineering
A function that:
3.3.1. Works to understand planned development activities and _ identify
requirements for new and amended environments and resources
3.3.2 Provisions required environments and resources through automated means
3.3.3 Monitors and maintains environment & resources health and stability;
3.3.4 Improves platform performance & observability;
3.3.5 I Optimises environment usage to reduce cloud consumption charges
3.3.6 Retires and decommissions environments that are no longer required
3.3.7. Maintains and monitors access control systems for all platforms,
environments and components
3.3.8 Advises sprint teams and other DDS Participants on security requirements
and vulnerabilities to ensure security is designed and built in at the earliest
opportunity
3.3.9 Ensures all platforms, environments and components have any necessary
security patches and updates deployed
3.3.10 Identifies and recommends tooling to automate security monitoring and
detection
3.3.11 Implements and manages any agreed security tooling
3.3.12 Reviews and monitors access logs to identify attempted unauthorised
access
3.3.13 Participates in Root Cause Analysis for security issues where required
3.4 Automation Engineering
A function that:
Schedule I3 Appendix 3 Version 15.0
Page 21 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
3.4.1. Works to understand planned code components and identify requirements
for the code release automation platform
3.4.2 Develop and maintain the code release automation platform;
3.4.3 Install, configure and update code release platform components as needed
3.4.4 Develop and maintain the central configuration store;
3.4.5 Maintain and promote release cycles to each environment
3.4.6 Creates and maintains Source Code repositories, branching strategies and
processes for deployment of code to repositories
3.4.7. Develop and maintain Test Automation solutions
3.4.8 Manages and schedules automated test scripts as part of an automated
deployment solution
3.4.9 Installs, configures and updates test automation components as needed
3.4.10 Manages code repositories for automated test scripts, data and other
artefacts
3.4.11 Creates and maintains test automation reporting
3.4.12 Defines and creates testing scenarios in collaboration with other functions of
the Platform Standing Team
3.4.13 Supports release and deployment activities as required
3.4.14 Resolves issues and defects in a timely manner utilising automation to
identify root cause
3.4.15 Creates and maintains Cl/CD automation reporting
4. OVERSIGHT ROLES
41 Delivery Lead
A Post Office participant who shall:
4.1.1. Schedule and arrange the Digital Demand Forecasting Board; and
4.1.2 Attend the monthly DDS Service Review meeting
4.1.3 Participate in product reviews and planning activities
4.1.4 Ensure that Post Office obligations and dependencies are delivered
4.1.5 Acts as a point of escalation for Fujitsu Services.
4.2 Release Manager
A Post Office participant who shall:
4.24
4.2.2
4.2.3
accept delivery from Sprint Teams;
manage test and release to live;
maintain visibility of Sprint planning activity;
Schedule I3 Appendix 3 Version 15.0
Page 22 of 50
CONFIDENTIAL
4.2.4
4.2.5
4.2.6
4.2.7
4.28
4.2.9
FUJ00234940
FUJ00234940
agree with the Product Owner when Sprint output is suitable for Release to
production;
manage dependencies and risks related to software release;
co-ordinate integration activities, stakeholders and third parties;
agree regression points and approve regression when required
schedule deployment activities; and
ensure all stakeholder communication takes place.
4.3 Test Manager
A Post Office participant who shall:
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
43.7
43.8
43.9
4.3.10
4.3.11
4.3.12
4.3.13
4.3.14
Create and maintain an overarching Test Strategy for all DDS Products
Create and maintain a risk-based Test Plan for each DDS Product
Define and own the test activities as part of an integrated Test and Release
process
Review and validate the test results delivered by each sprint
Confirm to the Release Manager that delivered code is ready for release
Own a continual service improvement plan for quality assurance activities
Ensure that the Test Strategy, Test Plans and processes are communicated
to all team members and stakeholders
Work with the Product Delivery Manager, Product Owner, Business Analysts
and Architects to understand the Product Roadmap for each product, and
identify the requirements for automated testing.
Identify, select and continuously review appropriate testing tools and
frameworks to meet the testing requirements.
Create and maintain a technical design for the fully automated test solution
to support all DDS Products
Support the Sprint Teams in the use and adoption of test automation tooling
Ensure consistency and standards in the creation of automated test scripts
across all products and teams through continuous review and feedback
Ensure that test coverage and quality statistics are produced automatically
and included in the agreed service reporting pack
Provide advice and guidance to the Sprint Teams as required
4.4 DDS Lead
A Fujitsu Services participant who shall:
44.1
44.2
Acts as Fujitsu Services single point of contact for Post Office Delivery Lead
Is accountable for the delivery of the entire DDS capability
Schedule I3 Appendix 3 Version 15.0
Page 23 of 50
CONFIDENTIAL
44.3
44.4
445
44.6
447
448
44.9
4.4.10
FUJ00234940
FUJ00234940
Manages demand, through the Digital Demand Forecasting Board, for all
existing products and new products
Manages overall resource provision to meet demand
Owns the metrics and reporting related to the services
Contributes to new Business Cases through sizing and estimation for
portfolios of work
Chairs and facilitates DDS Service Review meetings
Ensures timely billing and invoicing for all services, including calculation of
credits
Manages continual service improvement activities across the whole DDS
service
Deals with issues and escalations
4.5 The DDS Lead shall be a Key role for the DDS Term
4.6 Architecture Owner
A Fujitsu Services participant who shall:
4.6.1
46.2
4.6.3
4.6.4
46.5
4.6.6
46.7
Define and agree architectural documentation requirements for DDS
Products
Review and approve all design documentation produced during the Product
Initiation phase
Contribute to the architectural roadmap for DDS Products and services
Act as technical design authority for all DDS design decisions which do not
impact the Post Office enterprise architecture
Seek approval, via an agreed technical authorisation process for all DDS
design decisions which impact the Post Office enterprise architecture
Ensure that all solution designs are compliant with industry best practice and
published Post Office technical standards
Ensure that IPR ownership for all delivered components is registered as per
agreed processes.
47 The Architecture Owner shall be a Key role for the DDS Term
4.8 Solution Architect
A Post Office participant who shall;
48.1
4.8.2
4.8.3
Define and document the enterprise architecture within which DDS Products
must operate
Define and document any architectural principles and policies that DDS
Products must comply with
Provide timely review and approval of key architectural decisions required
for DDS Products
Schedule I3 Appendix 3 Version 15.0
Page 24 of 50
CONFIDENTIAL
FUJ00234940
FUJ00234940
4.8.4 Facilitate the approval of any change requests to the Post Office enterprise
architecture that are needed to facilitate development of a DDS Product
4.9 Release Co-ordinator
A Fujitsu Services participant who shall:
4.9.1 support the Release Manager in release planning activities
4.9.2 co-ordinate and schedule all Fujitsu Services activities related to a release
deployment
4.9.3 identify dependencies on other Fujitsu Services provided services in relation
to DDS releases
4.9.4 ensure release decisions and plans are communicated to all Fujitsu Services
stakeholders
4.9.5 act as a single point of contact for the Release Manager
5. PRODUCT ROLES
5.1 The roles in this section relate to individual Products.
5.2 Product Owner
A Post Office participant who, in respect of their Product, shall:
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.2.8
5.2.9
5.2.10
support Sprint Teams during development;
request User Stories to be added to the Product Backlog;
acts as Post Office’s point of contact for the Product Delivery Manager and
Sprint Teams;
maintains and articulates the Product Vision;
owns the Product Backlog content, definitively sets priorities and agrees
Acceptance Criteria with the Product Delivery Manager and is empowered
to make full and binding decisions on functionality and features that should
be included in the Product on behalf of the Post Office;
works with the Sprint Teams(s) to explain User Stories, clarify User Stories
and make decisions when requested on a daily basis;
participates in Sprint Review Meetings and confirms Sprint Requirements as
“done” in accordance with the Definition of Done;
participates in product review meetings and contributes to Product
Roadmap;
reviews and updates the relevant Product Backlog no less frequently than
fortnightly; and
communicates to Post Office stakeholders and users.
5.3 Product Sponsor
A Post Office participant who, in respect of their Product, shall:
Schedule I3 Appendix 3 Version 15.0
Page 25 of 50
CONFIDENTIAL
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3.7
FUJ00234940
FUJ00234940
be responsible for managing the stakeholders within the Post Office
organisation with a view to keeping each stakeholder engaged, informed and
supportive of the Product Vision and goals;
promote and champion the Product internally within Post Office;
review progress at product review meetings; and
act as the escalation point for issues within the Post Office.
ensure Budget is agreed for Product development and Release;
ensure that the Product receives the correct priority against other business
needs; and
ensure business value is delivered.
5.4 Product Delivery Manager
A Fujitsu Services participant who, in respect of their Product, shall:
5.4.1 act as Fujitsu Services’ single point of contact for the Product Owner and
Product Sponsor;
5.4.2 advise the Product Owner;
5.4.3. seek to ensure User Stories meet the Definition of Ready;
5.4.4 ensure Sprint Teams are resourced;
5.4.5 be accountable for the delivery of DDS for a Product;
5.4.6 ensure compliance with technical standards and ensure quality of
deliverables;
5.4.7. manage all Fujitsu Services resources responsible for delivery;
5.4.8 be accountable for the delivery of DDS for a Product;
5.4.9 Own and maintain the Product Roadmap and Release Plan for the Product;
5.4.10 Own the Metrics and reporting related to a Product;
5.4.11 Chair and facilitate product review meetings;
5.4.12 Mentor, coach and advise the Product Owner;
5.4.13 Deal with issues and escalations; and
5.4.14 Ensure compliance for identification and reporting of IPR ownership. The
Product Delivery Manager shall be a Key role for as long as the Product is
still progressed through DDS.
5.5 Solution Owner
A Fujitsu Services Participant who shall:
5.5.1
5.5.2
Define the architectural roadmap for a DDS product
Produce architectural documentation for the DDS product as agreed with the
Architecture Owner
Schedule I3 Appendix 3 Version 15.0
Page 26 of 50
CONFIDENTIAL
5.5.3
5.5.4
5.5.5
FUJ00234940
FUJ00234940
Seek and obtain all necessary approvals for architectural decisions related
to the product
Provide any necessary support to the sprint and standing teams to ensure
the architectural designs are realised
Ensure that IPR ownership for all delivered components is registered as per
agreed processes
5.6 UX Designer
A Post Office participant who shall:
5.6.1 Create and maintain a style guide describing the framework for the user
interface, and rules and guidelines for how to apply the style guide to
different requirements, scenarios and devices
5.6.2 Create a library of reusable assets for use by the development team when
building UI components
5.6.3 contribute to team estimates of User Stories and tasks;
5.6.4 engage with the Business Analyst, Product Owner and business
stakeholders in advance of Sprints to create and amend User Stories that
meet the INVEST criteria and document Acceptance Criteria for each;
5.6.5 engage with other team members to clarify and elaborate User Stories as
required during Sprint execution;
5.6.6 — work with the Business Analyst and Product Owner to visually capture user
requirements, using wireframes, mockups and other techniques to represent
what the delivered Product will look like;
5.6.7 work with the Business Analyst to map User Stories to business functions
and create a story map for approval by the Product Owner;
5.6.8 work with developers to ensure delivered code meets the requirements for
user interface and contributes to the creation of graphical assets for use by
developers;
5.6.9 create and update relevant documentation to agreed standards;
5.6.10 participate in agile ceremonies and follows the agreed agile processes;
5.6.11 actively participate in any other activities that are necessary to achieve the
agreed Sprint Requirements; and
5.6.12 maintain all necessary technical skills and qualifications as agreed and
defined in the Product Overview Document.
6. STANDARD SPRINT TEAM
6.1 ScrumMaster
A Fujitsu Services participant, who shall:
6.1.1
lead the Sprint Team and manage the agile process;
Schedule I3 Appendix 3 Version 15.0
Page 27 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
6.1.2 agree the Sprint Requirements with the Product Owner and Product Delivery
Manager and ensure delivery of the Sprint Requirements within the Sprint;
6.1.3 accept User Stories from the Product Backlog into the Sprint Backlog when
the Definition of Ready is met;
6.1.4 ensure that the Sprint Team reviews and confirms and/or refines estimates
of Story Points using the Estimation Model;
6.1.5 protect the Scrum Sprint Team from interference and distraction; and
6.1.6 conduct Sprint Retrospective Meetings and capture actions arising
6.2 Developer
A Fujitsu Services participant who shall:
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
6.2.7
contribute to team estimates of User Stories and tasks;
work with the Test Analyst, create, update and execute automated testing
scripts for functional unit testing;
create and update software code that meets the agreed technical standards
and satisfies the Acceptance Criteria and Definition of Done for assigned
User Stories;
create and update relevant documentation to agreed standards;
participate in agile ceremonies and follow the agreed agile processes;
actively participate in any other activities that are necessary to achieve the
agreed Sprint Requirements;
maintain all necessary technical skills and qualifications as agreed and
defined in the Product Overview Document.
6.3 Tech Lead
A Fujitsu Services participant who shall:
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
6.3.7
contribute to team estimates of User Stories and tasks;
work with the Sprint Team to ensure that software is created to an
architectural design that is consistent and maximises reuse of existing
assets;
ensure that code delivered is to a consistent quality standard
create and update relevant documentation to agreed standards;
participate in agile ceremonies and follow the agreed agile processes;
actively participate in any other activities that are necessary to achieve the
agreed Sprint Requirements; and
maintain all necessary technical skills and qualifications as agreed and
defined in the Product Overview Document.
6.4 Test Analyst
Schedule I3 Appendix 3 Version 15.0
Page 28 of 50
CONFIDENTIAL
FUJ00234940
FUJ00234940
A Fujitsu Services participant who shall:
6.4.1 contribute to team estimates of User Stories and tasks;
6.4.2 work with the Developers, Business Analyst and other team members,
create, update and execute automated testing scripts for functional unit
testing;
6.4.3. create and update relevant documentation to agreed standards;
6.4.4 _ participate in agile ceremonies and follow the agreed agile processes;
6.4.5 actively participate in any other activities that are necessary to achieve the
agreed Sprint Requirements; and
6.4.6 maintain all necessary technical skills and qualifications as agreed and
defined in the Product Overview Document.
6.5 Business Analyst
A Post Office participant who shall:
6.5.1 contribute to team estimates of User Stories and tasks;
6.5.2 engage with the Product Owner and business stakeholders in advance of
Sprints to create and amend User Stories that meet the INVEST criteria and
document Acceptance Criteria for each;
6.5.3 engage with other team members to clarify and elaborate User Stories as
required during Sprint execution;
6.5.4 work with the UX Designer to map User Stories to business functions and
create a story map for approval by the Product Owner;
6.5.5 work with the Test Analyst to ensure automated testing scripts satisfy the
Acceptance Criteria;
6.5.6 create and update relevant documentation to agreed standards;
6.5.7 _ participate in agile ceremonies and follow the agreed agile processes;
6.5.8 actively participate in any other activities that are necessary to achieve the
agreed Sprint Requirements; and
6.5.9 maintain all necessary technical skills and qualifications as agreed and
defined in the Product Overview Document.
7. GENERAL
7.1 In addition to the responsibilities described for each role above, Participants shall
respond to reasonable queries and/or reasonable requests for information from other
Participants as soon as reasonably possible.
7.2 In particular, any Participants which are provided by Post Office shall comply with
reasonable security-related requests arising from the Environment and Configuration
Engineering function of the Platform Standing Team.
Schedule I3 Appendix 3 Version 15.0
Page 29 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
APPENDIX 4
GOVERNANCE
Part 1
1. GENERAL
14
1.2
2.1
2.2
2.3
2.4
During the Transition Period, the parties shall review the contents of this Appendix 4
(Governance) and shall agree any required updates together with amended meeting
attendees, terms of reference for each meeting and meeting schedules. Wherever
possible, the parties will make use of existing meetings within the overall governance
structure under the Agreement (Schedule A2 Governance) to meet the governance
requirements under this Appendix 4 (Governance). Until such time as the content of
this Appendix 4 is superseded by a CCN, the remainder of this Appendix 4 shall
continue to apply.
All meetings shall be minuted.
MEETINGS
Digital Demand Forecasting Board
The Digital Demand Forecasting Board shall be conducted in accordance with
paragraph 7.1 of Schedule 13 (Digital Development Services)
The provisional attendees at the Digital Demand Forecasting Board are:
2.2.1 For Post Office:
(a) Post Office CIO Retail;
(b) Product Owner(s);
(c) Digital Development Lead; and
(d) Product Sponsor; and
2.2.2 For Fujitsu Services:
(a) Product Manager(s);
(b) DDS Lead; and
(c) Ops Director.
This list of provisional attendees shall be revised during the Transition Period through
the mutual agreement of the parties.
DDS Service Review
The DDS Service Review shall occur monthly.
The purpose of the DDS Service Review is to undertake a review across all Products
and the DDS as a whole to:
2.4.1 review the Agreed Metrics for the preceding month, assess the performance
of Fujitsu Services against the DDS Service Levels and determine any
Schedule I3 Appendix 4 Version 15.0
Page 30 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
2.5
14
1.2
1.3
Corrective Action and/or Service Credits (in accordance with Appendix 8
(Service Credit Mechanism));
2.4.2 jointly review a holistic service improvement plan with agreed actions on
either Fujitsu Services and/or Post Office as applicable to drive for ongoing
improvements to DDS;
2.4.3 approve any open adjustments to the Per Sprint Story Point Allocation for a
particular Sprint to reflect agreed impact of any Relief Event(s) on that Sprint;
and
2.4.4 resolve any disputes or escalations referred to it.
The provisional attendees for the DDS Service Review shall be:
2.5.1 Delivery Lead;
2.5.2 DDS Lead;
2.5.3 Post Office ClO Retail;
2.5.4 Post Office Vendor Manager;
2.5.5 Fujitsu Services Commercial Manager; and
2.5.6 representatives as required from the Product Owners and Product
Managers.
This list of provisional attendees shall be revised during the Transition Period through
the mutual agreement of the parties.
Part 2
AGREED METRICS AND REPORTING
The parties agree that reporting shall cover the following objectives:
1.1.1. measures for the monitoring and management of Sprints;
1.1.2. measures for the monitoring and management of the Platform Standing
Team; and
1.1.3. measures used for Service Credits.
Reports will be undertaken using data at source and compiled using automated
tooling such as Jira.
During the Transition Period, the parties will agree the specific metrics to be
measured and reported in respect of the Digital Development Services (the “Agreed
Metrics”). Fujitsu Services shall make available to Post Office a dashboard
comprising the Agreed Metrics. Some examples of metrics that may be agreed are
as follows:
Schedule I3 Appendix 4 Version 15.0
Page 31 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
Schedule I3 Appendix 4 Version 15.0
Page 32 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
APPENDIX 5
DDS CHARGES
1. CHARGES
14 In consideration for the provision of the Digital Development Services by Fujitsu Services,
Post Office shall pay to Fujitsu Services:
1.1.1 the Platform Standing Team Charges;
1.1.2 the Oversight Roles Charges;
1.1.3. the Product Team Charges;
1.1.4. the Sprint Team Charges;
1.1.5. the Product Initiation Charges;
1.1.6 any Burst Capacity Charges; and
1.1.7. the Tooling Charges,
as each such Charge is set out below.
1.2 The Charges shall be payable monthly in arrears and shall become due for payment
in accordance with the provisions relating to Charges as described within Schedule
D2 (Ordering, Invoicing and Payment).
1.3 Platform Standing Team Charges
1.3.1
The Platform Standing Team Charges shall be formed of two components:
(a) the applicable Fixed Platform Standing Team Charge as set out within the
Charges Table (Annex A); and
(b) the Variable Platform Standing Team Charge, calculated on a time
and materials basis on the basis of the DDS Rate Card, for any
additional capacity required for the provision of the Platform
Standing Team.
Prior to the DDS Commencement Date, Post Office shall sign a CT to cover the
Variable Platform Standing Team Charge to cover the period until the end of the first
three month period following the end of the Transition Period. The signature of such
a CT shall be considered a Transition Dependency. At the end of this first three
month period following completion the end of the Transition Period, the parties shall
consider whether any upward adjustment is required to the Fixed Platform Standing
Team Charge or amendment to the variable commercial model to reflect the usage
of resources which are the subject of the Variable Platform Standing Team Charge
during the aforementioned period. Such considerations shall include: (i) the number
of roles that are the subject of the Fixed Platform Standing Team Charge (with the
current Fixed Platform Standing Team Charge representing 3 FTEs); (ii) the number
of concurrent Sprint Teams that the Platform Standing Team are required to support;
and (iii) the variable commercial model for supporting incremental Sprints. The
parties shall aim to reach agreement on any such adjustment on or before 31
December 2018. Where any such adjustment is agreed, this shall be documented
Schedule I3 Appendix 5 Version 15.0
Page 33 of 50
CONFIDENTIAL
1.3.3
1.3.4
FUJ00234940
FUJ00234940
via a CCN. Where no such adjustment is agreed, the Variable Platform Standing
Team Charge shall continue to apply and be calculated on a time and materials
basis in accordance with the DDS Rate Card and Post Office must raise a further
CT to cover the Variable Platform Standing Team Charge as required.
Where in any given month the number of concurrent Sprint Teams exceeds
6 the parties shall agree any adjustment that may be required to the Platform
Standing Team and associated Platform Standing Team Charges.
The Fixed Platform Standing Team Charges (and the Variable Platform
Team Charges associated to Solar) shall be considered spend on
Committed Development Services (as defined in Schedule I1 to the
Agreement).
1.4 Oversight Roles Charges
1.4.1
1.4.2
The Oversight Roles Charges shall be as set out within the Charges Table
(Annex A).
The Oversight Roles Charges shall be considered spend on Committed
Development Services (as defined in Schedule I1 to the Agreement).
1.5 Product Team Charges
1.5.1
1.6.2
The Product Team Charges shall be calculated as follows:
# of Products x Per Product Charge,
Where:
e the # of Products refers to the number of distinct active Products in
relation to which Fujitsu Services are providing Digital Development
Services, as agreed between the parties; and
« The Per Product Charge is the applicable Charge for the Product Team
for the applicable Product (that shall be the amount listed within the
Charges Table (Annex A) unless otherwise agreed by the parties).
The Product Team Charges shall be considered spend on Committed
Development Services (as defined in Schedule I1 to the Agreement).
1.6 Sprint Team Charges
1.6.1
The Sprint Team Charges shall be calculated as follows (calculated for each
Sprint Team and then aggregated across all Sprint Teams):
# of Sprints x Per Sprint Charge,
Where:
« # of Sprints = the number of Sprints scheduled for completion by the
Sprint Team within the preceding calendar month; and
e Per Sprint Charge = the agreed charge per Sprint for the applicable
Sprint Team.
Schedule I3 Appendix 5 Version 15.0
Page 34 of 50
CONFIDENTIAL
1.6.2
1.6.3
1.6.4
FUJ00234940
FUJ00234940
The Per Sprint Charge for any given Sprint Team shall be as set out within
the Charges Table (Annex A), save where:
(a) Post Office requests Fujitsu Services to provide resources in place
of any Sprint Team resources which are Post Office roles or any
Post Office Participants (to the extent that Fujitsu Services is able
to provide such resources); or
(b) a particular Product requires additional resources over and above
the Standard Sprint Team Structure, within a given Sprint,
in which case, the parties shall agree an appropriate adjustment to the Per
Sprint Charge for such Sprint Team.
Where in accordance with the provisions of paragraph 6.2.3, Post Office
requires a Fujitsu Services Sprint Team participant to be replaced with a
Post Office Sprint Team participant then Fujitsu Services shall provide the
Post Office with a credit equal to 10% of the Per Sprint Charge per resource
so replaced which may be used to offset any further Sprint Charges for the
same Sprint Team.
The Sprint Team Charges shall be considered spend on Committed
Development Services (as defined in Schedule I1 to the Agreement).
1.7 Product Initiation Charges
1.7.41
1.7.2
Where Post Office requires Fujitsu Services to provide resources to support
Product Initiation in accordance with paragraph 8, then such resources shall
be chargeable on a time and materials basis in accordance with the DDS
Rate Card.
The Product Initiation Charges shall not be considered spend on Committed
Development Services (as defined in Schedule I1 to the Agreement).
1.8 Burst Capacity Charges
1.8.1
1.8.2
Where the parties agrees that additional resources are required from Fujitsu
Services above and beyond those resources which are the subject of the
Platform Standing Team Charges, the Oversight Roles Charges, the Product
Team Charges, the Sprint Team Charges and the Product Initiation
Charges, then such additional resource shall be chargeable on a time and
materials basis in accordance with the DDS Rate Card.
The Burst Capacity Charges shall not be considered spend on Committed
Development Services (as defined in Schedule I1 to the Agreement).
1.9 Tooling Charges
1.9.1
1.9.2
The Tooling Charges shall be as set out within the Charges Table (Annex
A).
The Tooling Charges shall not be considered spend on Committed
Development Services (as defined in Schedule 1 to the Agreement).
Schedule I3 Appendix 5 Version 15.0
Page 35 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
2.2
1.9.3 Once the list of tooling is finalised during the Transition Period in accordance
with Appendix 6 (Tooling), the parties shall review the Tooling Charges and
make any reasonably necessary adjustments to reflect the final list of tooling.
COMMITMENT
Subject to Fujitsu Services complying with the terms of this Schedule, the Post Office
hereby commits that the DDS Charges paid or payable in respect of each of the first
two fiscal years commencing 1 April 2018 (each such fiscal year being a “DDS
Commitment Year”) will equal or exceed £7,358,400 per annum, in the third fiscal
year, commencing 1° April 2020 it will equal or exceed £2,456,384, and in the
subsequent two fiscal years commencing 1st April 2021 and 1st April 2022 for
financial year 1st April 2021 to 31 March 2022 £1,034,602 for financial year 1st April
2022 to 31st March 2023 (the “DDS Commitment’). Fujitsu Services agrees that any
amount which has been spent to date on Development Services between the 1 April
2018 and the DDS Commencement Date will contribute towards the commitment for
the first DDS Commitment Year. The DDS Oversight Roles Service Charge and the
DDS Platform Standing Team Service Charge are excluded from the DDS
Commitment for the two latter DDS Commitment Years (those commencing on 1%
April 2021 and 1% April 2022). The parties agree that the DDS Oversight Roles
Service Charge and the DDS Platform Standing Team Service Charge (regardless of
the activities assigned to the personnel to whom the DDS Oversight Roles Service
Charge and the DDS Platform Standing Team Service Charge relate) shall constitute
Actual Spend for the purposes of the calculation in Schedule 11 (Revenue Switch
Mechanism).
Where Post Office in either the first or second DDS Commitment Years only fails to
meet the commitment set forth within paragraph 2.1 of this Appendix 5 (DDS
Charges):
2.2.1 by an amount equal to or less than £500,000, Post Office shall,
notwithstanding such shortfall, be deemed to have met such commitment in
respect of the given DDS Commitment Year provided that the Charges
within the four (4) month period immediately following the end of the
applicable DDS Commitment Year (the “Remedy Period”) exceed the
amount of the shortfall. For the avoidance of doubt, until such time as the
relevant shortfall is met, the Charges during the Remedy Period shall count
towards the shortfall only and not towards meeting any commitment in the
subsequent DDS Commitment Year (if applicable);
2.2.2 by an amount exceeding £500,000, Fujitsu Services may invoice Post Office
for the shortfall in excess of £500,000 and subsequently paragraph 2.2.1
shall apply in respect of the remaining £500,000 (by way of example, should
Post Office fail to meet the commitment by £600,000, Fujitsu Services may
invoice Post Office for £100,000, with the remaining £500,000 being then
subject to the Remedy Period specified within paragraph 2.2.1 of this
Appendix 5 (DDS Charges)); or
Schedule I3 Appendix 5 Version 15.0
Page 36 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
2.3
2.4
3.2
3.3
3.4
3.5
3.6
2.2.3. by any amount following the end of the applicable Remedy Period, Fujitsu
Services may invoice Post Office for the shortfall at any time following the
end of the relevant Remedy Period (as applicable).
With respect to the final three DDS Commitment Years (ending 31st March 2021,
31st March 2022 and 31st March 2023) paragraphs 2.2.1 to 2.2.3 shall not apply.
Instead, if, in one of the final three DDS Commitment Years, Post Office exceeds the
DDS Commitment for that DDS Commitment Year then the excess shall be credited
against any shortfall in the DDS Commitment for the following DDS Commitment
Year. If, after applying such credit, there remains a shortfall within one of the final
three DDS Commitment Years then Fujitsu Services shall be entitled to invoice Post
Office for such shortfall at the end of the relevant DDS Commitment Year.
Paragraph removed by CCN1670a
ORDERING OF SPRINT TEAM CAPACITY
Subject to paragraph 3.8 below, the parties shall agree the number of Sprint Teams
at the Digital Demand Forecasting Board.
Sprint Teams shall be agreed and ordered in blocks of 6 Sprints to cover a 12-week
period.
Each block of Sprints shall be ordered at least 90 days in advance of their
commencement. For example, the Digital Demand Forecasting Board meeting in
March would order Sprints commencing no earlier than July
Post Office shall confirm the Sprint Team capacity in writing through the minutes of
the meeting and Fujitsu Services shall ensure that the ordered capacity is ready to
commence work in accordance with such order for each ordered Sprint.
Once ordered Sprints can only be adjusted on less than 90 days’ prior notice pursuant
to paragraph 3.6 (for the avoidance of doubt, this shall not affect the ability for the
Digital Demand Forecasting Board to adjust such Sprints with more than 90 days’
prior notice).
Where Post Office requests a change in accordance with paragraph 3.5 the following
shall apply;
3.6.1 Where there is a request to increase the number of Sprint Teams and using
reasonable endeavours Fujitsu Services is able to meet the request, Post
Office shall pay the Charges for such additional Sprint teams in accordance
with paragraph 1.6 above.
3.6.2 I Where there is a request to decrease the number of Sprint Teams allocated
to a specific Product or the number of Sprints then, in addition to the general
ability for the Digital Demand Forecasting Board to reallocate Sprint Teams
between Products, then with Fujitsu Services’ agreement, Post Office may
require the Sprint Teams that are the subject to the reduction request to
undertake other activities not contained within a Product Backlog
(‘Additional Activities”), provided that such Additional Activities are
reasonably within scope of the capabilities and expertise of the applicable
Schedule I3 Appendix 5 Version 15.0
Page 37 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
3.7
3.8
4.2
Sprint Team. In such circumstances: (i) the Charges for such Sprint Team
shall remain as scheduled for the applicable period; and (ii) any work
undertaken by such Sprint Team in respect of any Additional Activities shall
be excluded from any assessment of performance by such Sprint Team
pursuant to Appendix 8.
The parties have agreed the initial Sprint Team capacity (being two Sprint Teams)
and following the DDS Commencement Date, Fujitsu Services shall stand up this
number of Sprint Teams and this shall be the minimum number of Sprint Teams
during the first 90 day period following the DDS Commencement Date (the “Ramp-
Up Period”). During the Ramp-Up Period, Fujitsu Services agrees that Post Office
may increase the number of Sprint Teams up to a maximum of 4, provided that:
3.7.1 Post Office provides Fujitsu Services with at least 30 days’ prior notice of the
requirement for an additional Sprint Team;
3.7.2 I where more than 3 concurrent Sprint Teams will be required before 60 days
after the DDS Commencement Date, any additional requested concurrent
Sprint Teams will be subject to paragraph 3.6.1;
3.7.3. where more than 4 concurrent Sprint Teams will be required before 90 days
after the DDS Commencement Date, any additional requested concurrent
Sprint Teams will be subject to paragraph 3.6.1; and
3.7.4 each Sprint Team uses the Standard Sprint Team Structure.
The provisions of this paragraph 3.7 are without prejudice to paragraph 3.6.1.
Within 10 business days of the DDS Commencement Date the parties shall hold a
Digital Demand Forecasting Board and agree and or confirm the number of Sprint
Teams for the next block of 6 Sprints following the Ramp-Up Period.
Annex B contains worked examples of the planning approach for the initial Digital
Demand Forecasting Board.
GENERAL
All amounts set out in this Appendix 5 (DDS Charges) are before adjustment for RPI
as set out in paragraph 16 of Schedule D1 (Charges) and exclusive of VAT.
All monthly Charges relate to calendar months.
Schedule I3 Appendix 5 Version 15.0
Page 38 of 50
CONFIDENTIAL
ANNEX A — CHARGES TABLE AND DDS RATE CARD
All Charges are set out in GBP Sterling and are exclusive of VAT.
Fixed Charges
Resource
Unit
Charge (£
DDS Summary ex VAT) I Charging Basis
DDS Oversight Roles
Service Charge 78,441 Monthly Charge
DDS Platform Standing Team
(Initial Fixed Platform Standing Team I 58,034 Monthly Charge
Service Charge)
DDS Product Roles
Service Charge 39,146 Charge per Product Team per
month
DDS Tooling Charges
Variable Service Charge 2,055 Charge per Sprint Team per
month
DDS Sprint Consumption
Charge
Blended Teams 54,767 Charge per Sprint Team per
month
Schedule I3 Appendix 5 Version 15.0
Page 39 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
DDS Rate Card
Role
Charge per Day (ex VAT) Minimum Experience
FUJ00234940
FUJ00234940
Level
Junior Software Engineer 634 A
Senior Software Engineer 901 B
Test Automation Analyst 901 A
Junior Business Analyst 901 A
Platform Engineer 901 A
Tech Lead 901 B
UX Designer 901 A
Senior Business Analyst 1,014 B
Release Controller 1,014 B
Scrum Master 1,014 B
Product Manager 1,165 Cc
Solution Owner 1,165 c
Text Architect 1,165 B
Platform Lead Engineer 1,165 B
Architecture Owner 1,756 c/D
Agile Coach 1,756 D
DDS Lead 1,756 D
Experience definitions
0 0 UD >
3-5 years relevant IT experience with
some industry knowledge
5-10 years relevant IT experience
with good industry knowledge
10+ years relevant IT experience with good industry
knowledge, management experience
15+ years relevant IT experience,
through leader
Schedule I3 Appendix 5 Version 15.0
Page 40 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
ANNEX B - DIGITAL DEMAND FORECASTING NOTICE TIMESCALES
Fujitsu - Post Office Digital Demand Forecasting Board Meeting Date: 1stJuly 2018
Post Office Attendees: POL Digital Lead, POL Retal lo, Product A Product Owner, Product & Product Owner, Release Manager
1 DDS Lead, Fi Product Delivery Manager,
‘Sprint Commitment (2 sprints per team per month)
Product AUgIB Sep-18 O18 Nov-18 Dect8 Jant9 Feb-19 Mar19 Apr-19. May-19 Jun-19 Jul:t9 Aug19_Sep-19.
Product A
Previous Commitment 2s 4 6 6 6 fie 6 poe bos
[New commitment Etc wa « I « ls bathe ace eee ee ew]
Product 8
Previous Commitment a
[New commitment [ [2 [2 I
Product
Previous Commitment
[New Commitment i I i 1]
‘otal Sprint Commitment
Previous Commitment 2 4 4 6 6 66 6 Beles Belge yi ep
[New Commitment [eile ey « le il sé Phe ere ie eles a]
key Previously committed, cannot be changed, ae within 90<day period
[New Commitment, changeable up to 90 days prior to sprint start
Forecast for information only, can be changed up to 90 days prior to sprint start
Schedule I3 Appendix 5 Version 15.0
Page 41 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
APPENDIX 6
TOOLS
Fujitsu Services will provide appropriate tooling for all Products for use by both Fujitsu Services and
Post Office resources in order to provide DDS:
4
2
3
4
) Atask tracking scheduling tool;
) Accollaborative document and knowledge management repository;
) A.collaborative communication and messaging tool; and
) Acode quality analysis tool.
Fujitsu Services will procure licences for each DDS Participant as defined in this Schedule I3
and in addition for up to 24 additional Post Office users.
If Post Office require additional licences with respect to any of the above tooling, Fujitsu
Services shall provide a price on request.
Any Product specific tooling requirements will be agreed during Product Initiation.
The final list of tooling will be agreed during the Transition Period and this Appendix 6 shall be
updated accordingly via a CCN.
Schedule I3 Appendix 6 Version 15.0
Page 42 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
APPENDIX 7
INTELLECTUAL PROPERTY RIGHTS TRACKER
In determining whether the IPR in any of the Software to be created pursuant to a Product (or
a Release) is a Listed Right, the Fujitsu Services Architect Owner shall, as part of Product
Initiation consider the requirements and the manner in which the Sprint Requirements could
be delivered by Fujitsu Services. The Architect Owner will liaise with the Product Delivery
Manager and the Product Owner to discuss and agree the IPR strategy for the Product. An
agreed IPR strategy will be contained within the Product Initiation deliverables.
Any changes to the Product Initiation deliverables that relate to FJ Digital Background IPR, KS
IPR or Horizon IPR will be updated as part of any relevant Sprint Review. With respect to the
use of open source or third party IP Rights, recognising the requirement for the Sprint Team
to be able to deliver the User Stories in the most efficient manner possible, the use of any
such open source or third party IP Rights shall be tracked as part of the Sprint Review Report.
To the extent that there is a change to the Product requirements following Product Initiation
that relate to the usage of FJ Digital Background IPR, K5 IPR or Horizon IPR, the Fujitsu
Services Architect Owner shall escalate to the Product Owner and the Delivery Lead such that
the parties may agree upon any revision to the IPR strategy and the same will be tracked
within the updated Product Initiation deliverables accordingly. The parties acknowledge that
such a change in the Product may require the Sprint Team to be re-set prior to re-commencing
the Product delivery.
The Product Owner shall be responsible for ensuring that Post Office’s Chief Technical Office
(or nominated representative) agrees to the IPR strategy (including any changes to the IPR
strategy) with respect to any Sprint Requirement which is to be designed, coded or supplied
as a pre-existing component or an algorithm using any Listed Rights prior to formally approving
the Product to be delivered under DDS.
Schedule I3 Appendix 7 Version 15.0
Page 43 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
APPENDIX 10
TRANSITION
During the course of the Transition Period the parties shall review and agree the contents of the
following Appendices:
e — Appendix 3 (DDS Participants);
e Appendix 4 (Governance); and
e — Appendix 6 (Tooling),
as set out within such Appendices.
Where Post Office fails to meet a Transition Dependency then, to the extent that such failure directly
impacts a Sprint, the failure shall be a Relief Event for the purpose of the relevant Sprint and Fujitsu
Services shall comply with paragraph 11.
Schedule I3 Appendix 10 Version 15.0
Page 44 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
14
2.1
3.1
APPENDIX 8
SERVICE CREDIT MECHANISM
DEFINITIONS AND INTERPRETATION
In this Appendix, the following terms and expressions shall have the meaning set out
below:
“Average Sprint Performance” means in respect of a given Sprint Team, subject to
paragraph 3.1.3 of this Appendix 8 (Service Credit Mechanism), the average
Completion Rate over the previous six Sprints completed by such Sprint Team;
“Completion Rate” means in respect of a given Sprint, the percentage of Story Points
that were scheduled for completion during such Sprint that were actually completed
during such Sprint;
“Expected Service Level” means, in respect of a given Sprint, the expected target
percentage (as set out as the ‘expected’ percentage within Attachment 1 to this
Appendix 8 (Service Credit Mechanism)) of the Story Points due for completion during
such Sprint;
“Improvement Plan” has the meaning given to it in paragraph 4.1 of this Appendix 8
(Service Credit Mechanism);
“Minimum Service Level” means, in respect of a given Sprint, that at least 75% of the
Story Points due for completion during such Sprint were actually completed and
Accepted;
“Sprint Charges” means, in respect of any given Sprint, the total charges payable by
Post Office in respect of such Sprint;
“Sprint Service Credit” means, in respect of any given Sprint, ten per cent (10%) of
the Sprint Charges; and
“Threshold Service Level” means, in respect of a given Sprint, the threshold target
percentage (as set out as the ‘threshold’ percentage within Attachment 1 to this
Appendix 8 (Service Credit Mechanism)) of the Story Points.
SERVICE LEVEL PRINCIPLES
During each Sprint, Fujitsu Services shall provide the Services to a level that meets or
exceeds the Expected Service Level for such Sprint and Fujitsu Service’ performance
against this target shall be measured and reported in accordance with this Appendix.
SERVICE LEVEL MEASUREMENT
Reporting
Schedule I3 Appendix 8 Version 15.0
Page 45 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
44
4.2
5.1
3.1.1 During each Sprint, Fujitsu Services shall measure its performance against
the Expected Service Level, Threshold Service Level and Minimum Service
Level for such Sprint.
3.1.2 Within the DDS Service Review, Fujitsu Services and Post Office shall review
Fujitsu Services’ performance during the previous two Sprints. Fujitsu
Services shall provide sufficient evidence of its performance during such
Sprints to allow assessment of its performance.
3.1.3. Where the period for assessing the Average Sprint Performance of any given
Sprint Team includes any Disrupted Sprints, such Disrupted Sprints shall be
discounted from the calculated average. By way of example only, where the
relevant 6 month period contained 1 Disrupted Sprint, the Average Sprint
Performance shall be calculated as an average of the remaining 5 Sprints
within such period. Where the number of Disrupted Sprints within any such
period exceeds 2, the period shall be extended until an average can be taken
across at least 4 Sprints that are not Disrupted Sprints.
CORRECTIVE ACTION
Creation of an Improvement Plan
Where, in respect of any Sprint, the Completion Rate fails to meet the Expected
Service Level in respect of such Sprint, Fujitsu Services shall, within 5 business days
of the end of such Sprint, provide Post Office with a written plan for improving Fujitsu
Services’ performance, so as to improve Fujitsu Services’ performance and satisfy
such Service Levels in the future (an “Improvement Plan”) for Post Office’s approval.
In the event that Post Office (acting reasonably) does not approve the Improvement
Plan, Fujitsu Services shall submit a revised plan to address Post Office’s concerns.
For the avoidance of doubt, an Improvement Plan may result in an individual resource
being removed from a Sprint Team where the parties agree that this is an appropriate
action to help to address Fujitsu Services’ performance issues).
Implementation of Improvement Plan
Upon Post Office’s approval, the Improvement Plan shall be implemented by Fujitsu
Services in accordance with the timescales set out in the Improvement Plan and
Fujitsu Services shall bear the cost of performing its obligations and responsibilities
under such Improvement Plan. During the implementation of such Improvement Plan,
Fujitsu Services shall provide to Post Office weekly status reports containing
progress updates until such time as Fujitsu Services’ performance is fully evidenced
to be in compliance with the applicable Service Level. For the avoidance of doubt, the
implementation of the Improvement Plan shall not relieve Fujitsu Services of any
obligations hereunder or from incurring additional Sprint Service Credits.
SPRINT SERVICE CREDITS
This paragraph 5 of Appendix 8 (Service Credit Mechanism) shall not apply until 1
November 2018.
Schedule I3 Appendix 8 Version 15.0
Page 46 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
5.2
5.3
5.4
5.5
6.1
Calculation
Where, in respect of any Sprint, the Completion Rate fails to meet:
(i) the Minimum Service Level (a “Minimum Service Level Default”); or
(ii) the Threshold Service Level (but does not fail to meet the applicable Minimum
Service Level) in respect of such Sprint and the Average Sprint Performance
by Fujitsu Services does not exceed the Threshold Service Level,
then, subject to paragraphs 5.3, 5.4 and 5.5 of this Appendix 8 (Service Credit
Mechanism), Fujitsu Services shall pay to Post Office an amount equal to the Sprint
Service Credit for the applicable Sprint, which shall be applied as a credit for the next
invoice as a separate line item.
In no circumstances will the total amounts payable by Fujitsu Services in Sprint Service
Credits for any given Sprint exceed 10% of the Sprint Charges for such Sprint.
Subject to paragraph 6.1 of this Appendix 8 (Service Credit Mechanism), but without
prejudice to paragraph 4 (Corrective Action), the payment of Sprint Service Credits
shall be the Post Office’s sole remedy with respect to any failure to meet the Service
Levels.
Where a new Product is introduced to the DDS Service or a new Sprint Team
commences (as described in the table set out in Attachment 1 to this Appendix 8
(Service Credit Mechanism)), then the Threshold Service Level shall apply for the first
3 or 5 Sprints (as applicable) prior to it becoming set at the “Existing Team” levels. For
the purposes of calculating the Average Sprint Performance across 6 Sprints which
include new Products or new Sprint Teams, the Threshold Service Level will be
calculated as the average of the Threshold Service Level targets across all of the 6
Sprints for the purposes of determining whether a Sprint Team has meet the Average
Sprint Performance. An example of this process is set out beneath the table in
Attachment 1 to this Appendix 8 (Service Credit Mechanism).
TERMINATION
Where the average Completion Rate across any twelve (12) consecutive Sprints
across all Sprint Teams commencing at any time after 1 November 2018, fails to meet
the Threshold Service Level (“Critical Service Failure”), then, notwithstanding
paragraph 5.4 of this Appendix 8 (Service Credit Mechanism), provided that during
such period there were an average of at least four (4) Sprint Teams running
consecutively, Post Office may terminate the Digital Development Service a result of
Default by Fujitsu Services by giving Fujitsu Services no less than sixty (60) days’ prior
written notice. In the event of any Critical Service Failure, paragraph 5.4 of this
Appendix 8 (Service Credit Mechanism) shall cease to apply.
Schedule I3 Appendix 8 Version 15.0
Page 47 of 50
CONFIDENTIAL
FUJ00234940
FUJ00234940
6.2 If, in the event of a Critical Service Failure, Post Office commences proceedings
against Fujitsu Services in respect of the provision of the Digital Development Services
by Fujitsu Services in relation to one or more Products, Fujitsu Services shall not be
required to (but may if it so chooses to) provide further Digital Development Services
in respect of such Product(s) and Fujitsu Services or Post Office may elect for Fujitsu
Services to cease to provide Digital Development Services in respect of such
Product(s) on providing at least 10 business days’ prior written notice to Post Office,
and in that case:
6.2.1
6.2.2
6.2.3
6.2.4
Fujitsu Services will use all reasonable endeavours to procure an orderly and
efficient transition from the provision of the DDS for the Product so terminated
to the Post Office or a Replacement Service Provider;
for the avoidance of doubt, Fujitsu Services shall continue to provide Digital
Development Services in accordance with this Schedule I3 in respect of all
other Products;
the Charges relating to the Product Roles and the Sprint Teams associated
with the terminated Product shall cease to apply from the date of termination
(the “Product Reduction Amount”) and the Charges related to the Platform
Standing Team Charges and the Oversight Roles Charges shall be reviewed
by the parties with a view to reducing them by a percentage equal to the
average Sprint Team Charges for the affected Product(s) over the previous 6
month period as a proportion of the DDS Charges (excluding the Platform
Standing Team Charges, Oversight Roles Charges and Tooling Charges)
until such time as new Products are introduced or additional concurrent Sprint
Teams are engaged to support existing Products that require additional
resources within the Platform Standing Team or Oversight Roles, or such
other proportion taking reasonable account of the continued provision of DDS
(the “Product Reduction Percentage”). The DDS Commitment for the
remainder of the current DDS Commitment Year and for each subsequent
DDS Commitment Year shall also be reduced by the Product Reduction
Amount and, for so long as it applies, by a percentage equivalent to the
Product Reduction Percentage; and
the annual liability cap referenced in Clause 14.1(ii) shall be reduced by the
Product Reduction Amount for each subsequent year of the DDS Term and,
for so long as it applies, (for each subsequent year of the DDS Term) by a
percentage equivalent to the Product Reduction Percentage.
Schedule I3 Appendix 8 Version 15.0
Page 48 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
ATTACHMENT 1 TO APPENDIX 8
Target Story Point Percentages
Number of Sprints Completed by Standard Sprint Teams
Type of Sprint Team i aie 2 3 4 5 6+
Existing Team I Expected 90% 90% 90% 90% 90% 90%
Threshold 85% 85% 85% 85% 85% 85%
New Product* Expected 75% 75% 75% 85% 85% 90%
Threshold 75% 75% 75% 75% 75% 85%
New Team** Expected 85% 85% 85% 90% 90% 90%
Threshold 75% 75% 75% 85% 85% 85%
* A ‘New Product’ Sprint Team refers to a Sprint Team supporting a new Product that has not
previously formed part of the scope of activity undertaken by Fujitsu Services as part of the
Digital Development Services. For clarity, an Existing Team moving to a New Product will
have the New Product measures applied.
** A ‘New Team’ Sprint Team refers to any new Sprint Team created to provide support for an
existing Product that already forms part of the scope of activity undertaken by Fujitsu Services
as part of the Digital Development Services.
** The number of Sprints completed by a Sprint Team refers to the number of concurrent
complete Sprints undertaken by the specific Sprint Team in question, starting from the first
Sprint undertaken by that Sprint Team since the last Product Initiation.
WORKING EXAMPLE
Working Example of calculating Average Sprint Performance where the Threshold Service
Level is at different figures during the 6 Sprint measurement Period.
NEW PRODUCT
Threshold is 75 Story Points for first 5 sprints, then 85 for subsequent sprints
Anew Product is introduced and the Sprint Team performs as follows:
Schedule I3 Appendix 8 Version 15.0
Page 49 of 50
FUJ00234940
FUJ00234940
CONFIDENTIAL
int Number 2 2 a 4 2 é 40 a 42
Minimum or i i i i i A
Threshold 75 75 75 75 75 8 8 8 8 85 8 85
6 sprint avg Threshold inn 76.7 "78.3 "800 "817 "833 "85.0 " 85.0
Delivered [76 I 84 I #8 I 92 I 96 I 100 I 100 I 100 I 100 I 100 I 100 I 100 I
6 sprint avg delivered 89.3 93.3 96.0 98.0 99.3 100.0 100.0
Credits o 0 0 0 0 0 0 60 60 0 o 0
The 6 Sprint Average Threshold for Sprint 6 onwards will be calculated as shown in the table
above for the purposes of measuring whether the Threshold Service Level and the Average
Sprint Performance has been met.
NEW TEAM FOR EXISTING PRODUCT
Threshold is 75 Story Points for first 3 sprints, then 85 for subsequent sprints
Anew Sprint Team is introduced and performs as follows:
$28 4 78 Oe
Minimum 7S 75 75 75 75 75 7s 75 75 75 75 75
Threshold 7575 75 85 8 8 8 8 8 8 8 85
6 sprint avg Threshold i so.0 "31.7 "83,3 "85.0 "850 "85.0 ” 85.0
Delivered [76 I 84 I a8 I 92 I 96 I 100 I 100 I 100 I 100 I 100 I 100 I 100 I
6 sprint avg delivered 89.3 93.3 96.0 98.0 99.3 "100.0 100.0
Credits 0 0 0 0 0 0 06 0 0 0 0 0
The 6 Sprint Average Threshold for Sprint 6 onwards will be calculated as shown in the table
above for the purposes of measuring whether the Threshold Service Level and the Average
Sprint Performance has been met.
SPRINT TEAMS COMMENCING PRIOR TO 1ST NOVEMBER
A new Sprint Team commences DDS on 1* October. For Sprints 1 and 2, Service Levels
shall be measured but no Service Credits will apply. For Sprints 3 onwards, the Threshold
Service Levels and Expected Service Levels will be as per the table but Service Credits will
apply.
Schedule I3 Appendix 8 Version 15.0
Page 50 of 50