The document outlines the sections and structure of a new programme to develop a banking solution. It describes 12 sections that will make up the programme including programme management, resource management, product backlog, sprint planning, and governance. It provides details on the programme management structure including steering committees, product owners, and squads for different functional areas. It also includes examples of the high-level product backlog and sprint planning.

1. New BIZ
Programme
logo

2. Sections
1. PROGRAMME MANAGEMENT
2. PROGRAMME MANAGEMENT (SQUADS)
3. RESOURCE MANAGEMENT & FINANCIALS
4. TOM & HL FUNCTIONAL DESIGN
5. PRODUCT BACKLOG
6. HL PLAN
7. SPRINT PLAN
8. PROGRAMME GOVERNANCE
9. PROGRAMME REPORTING
10. RISKS & ISSUES
11. PROGRAMME TESTING

3. Migration
Squad
Business
Teams
PROGRAMME MANAGEMENT
Steering Committee
Programme Manager
Customer
Servicing
Product
Owner
Debit
Product
Owner
Credit
Product
Owner
Operations
Product
Owner
Integration
Product
Owner
Infrastructure
Team
Customer
Servicing
Squad
Debit
Squad
Credit
Squad
Operations
Squad
Integration
Squad
Scrum Master
The Programme Management will consist in multiple layers of
Steering Committee will assist to programme teams to meet the vision and scope by providing resources, budget, tools and guidance.
Programme Manager will ensure scope and financials are aligned to vision and scope. PM will report to SteerCo in monthly basis and address priority
actions to ensure any impediment are resolved timely.
Product Owners are part of business areas and are the point of contact and support for Squads. They will
Business Teams aim to define and assist to PO on business
requirements and the vision of solution.
Squads will consist in a Lead and Development Teams. They are
the core of development and will require Product Owners and
Business teams to address definition of Product Backlog.
Scrum Master role aims to assist Product Owners and Squads to
ensure velocity of development and remove impediments or
issues that slow down the development. Also it will provide clarity
to move across the governance framework.
Infrastructure Team aims to ensure all software/hardware are
timely implemented and any technical request from Squads are
addressed.
Migration Squad aim to migrate data from legacy systems and are
involved in all development to migrate data to solution developed.

4. PROGRAMME MANAGEMENT (SQUADS)
PMO & DesignCust Squad Debt Squad Cred SquadOps Squad
Mtg
Dev
Scrum
Dev
Product Owner Product Owner Product Owner Product Owner
Scrum
Dev
Mob
Dev
Integration Dev
- Customer Website
- Mobile app
- Brand website
- Ops front
- Cust Comms
- Bank Acct
- Debit Card
- Deposits
- Acquisitions
- Credit Card
- Credit Acct
- Loans
- Sales
- General Ledger
- Reg Rep
- Risk
- DWH
Mob
Dev
Integration Dev
Web
Dev
Web
Dev
Hub
Dev
Scrum
Dev
Comm
Dev
DWH
Dev
Acct
Dev
Cust
Dev
Payments
Dev
Adqui
Dev Dev Risk Dev
Scrum
Dev
Integration Dev
Loan
Dev
Credit
Dev
RR
Dev
Cust Lead Debt Lead Ops Lead Cred lead
Integration Lead
The project resources, following the scrum framework, would consist in
different Squads dedicated to specific functional areas with a unique
transversal Squad, Integration.
These would be the functional areas assigned:
Cust Squad Debt Squad Ops Squad Cred Squad Integtn Squad
- Integrations
- File Hub
- Payments
- Rest services
Each Squad will have multiple roles and skills dedicated to their functional
area.
Some Squads may not participate from the beginning of the programme due
to stories and requirements may be discover during the process of
developing functionalities.
Initial requirements may bring some insight of future developments but due
to the Agile approach, some requirements may not be defined until
functionalities are developed.
Integration team will require to be updated for any development and should
have across technical skills to assist other squads and to allow fast response
to integration between platforms.
Migration Squad is specific team to
perform migration to the solution defined.
For this reason, Squad should be involved
in every development to allow data
mapping, data quality review, generate
data for testing and ensure legacy data is
migrated accordingly to business needs.
Integration
Squad
Migration Squad

5. RESOURCE MANAGEMENT & FINANCIALS
Resources are key to the programme to manage and deliver the Solution aligned to Business Strategy. Programme needs to ensure that all roles and
responsibilities are covered to ensure project success.
An initial Resource plan is required and further review may be required for addition of resources and roles. Plan also would require to include capacities
and capabilities due to some resources will be assigned across workstreams and responsibilities.
FINANCIALS
Resource planning would be used as key mechanism to
control Resource cost.
An initial budget will be assigned to each squad which can be
modify/increase with Change Control process.
Monthly Financial review will be part of SteerCo report.
Sprint 9 Sprint 10
TotalDays
TotalCost
DaysForecast
ForecastCost
Resource
Man/day
Rate
Previous
Springs
week1
week2
week3
week4
week1
week2
week3
week4
week5
Product Owner 200 35000 5 5 5 5 5 5 5 5 320 64000 105 21000
Lead Dev 200 35000 5 5 5 5 5 5 5 5 320 64000 105 21000
Web Dev 200 35000 5 5 5 5 5 5 5 5 320 64000 105 21000
Web Dev 150 17250 5 5 5 5 5 5 5 5 260 39000 105 15750
Mob Dev 150 16500 150 22500 40 6000
Mob Dev 150 12750 5 5 5 5 115 17250 105 15750
Comm Dev 150 13500 5 5 5 5 5 5 5 5 210 31500 99 14850
Integration
Dev 200
0 5 2 2 5 2 2 2 2 5 229 45800 0 0
20 20 20 20 25 20 15 15 25 348.050 115.350
Shared Resources
Cust Squad Debit Sq Credit Sq Integra Sq Ops Sq
During the development, it’s expected to have some resources
to be shared across Squads which will be control and manage
(as the example) to ensure forecasting and budget are not
overrun.
Sharing resources among squads aim to accomplish the scope
for the Sprint and identify is further roles and skills are needed
between the squads.

6. Customer
Channels
TOM & HL FUNCTIONAL DESIGN
Acquisitions
Cust Check
Bureaus
SEPA
File Hub
ETL
Staging Area
IVR
Website
Bank of Spain
Regulatory Reporting
App
filesrest services
CTI/Dialler
Bank / Debit
system
deposits
debit card
bank
account
Credit
system
credit card
credit acct
Rest
Serv
CallCenterfront
Cross
Selling
Cust
Comms
DWH MI
General
Ledger
REDSYS
Insurance
Doc Image
Agencies
Score
Decision
sales
campaigns
Cust Serv
log on
Authentication
Auth
Collections
Operationsfront
loans
ORANGE TELCO
Prospect Cust
Migration

7. PRODUCT BACKLOG (I)
HL Product Backlog Areas Content
Installation Dev environment CORE, Front, File Hub, DWH, Connectivity
Customer Develop Details, contact, 2nd Cust
Bank Account Details, Cust-Acct relationship
Debit Card Details, Cust-Debit Card relationship
Payments SEPA, PRICE, Transfers, Rejections, M-Pay
Acquisition Cust check, bureaus, risk, rules
Customer Web Access, Details, Extract, Bills, Transfers, Payments
Mobile app Access, Details, Extract, Transfers, Payments
Risk Solvency, Credit Score, Rules
Cust Comms Telephony, Chat, letters, sms & email
Loans Details, Solvency, Risk
Sales Campaigns, Cross Selling, Black List, Risk, Rules
Credit Card Details, Cust- Credit Card relation
Financials, Monthly-Revolving
Regulatory Reporting DWH, FINREP, COREP, GDPR, Cirbe, Bureaus
Cust Web Product Backlog Items
Responsive Web Automatic logout Re-issue Debit card
Security Accessibility Alerts (sms, email, txt)
Logon credentials One time password E-Statement
Landing web Main Services Inbox
Online Onboarding Segmentation Chat
New Cust Registration Acct-card selection Bills and receipts
Acct & Card activation New product request Doc repository
Authentication Additional card request Content Management
Remember User name Acct details change Traceability records
Forgot Password Logon credentials change Reports
Telephony Product Backlog Items
IVR services Agent Call distribution Dialler
Incoming lines Call recording Call Scripts
Segmentation Distr Call tracing Reporting & Tracking
Security – ID&V Payments Sales offers
Customer survey Authorizations Customer Check
Customer request Payments/DD Retention
Disputes Worklist
Comms Product Backlog Items
Letters Segmentation Enrolment
Statements Targets Campaigns reports
Fee Alerts Robinson list
Endorsements Campaigns Do not contact
Push notifications Cross sales Complaints
SMS & email Criteria Measurements
Bank Account Product Backlog Items
Bank Account IBAN Transfers
Customer details Payments – SEPA Statements
Address details Direct Debits Fees & charges
Customer Related Rejections
Debit Card Product Backlog Items
Bank Account PAN Records
Customer relationship PIN management Redsys
Credit Card Product Backlog Items
Products EPP PRICE
Revolving Insurance m-Wallet
Plans Payments
Customer Product Backlog Items
Customer Details Records
Customer relations Products History
The project would follow the agile
framework and Product Backlog and
Sprint Backlog would be created from
High Level Requirements.
The example of HL Product Backlog
contains the main areas of development.
These areas will require a details product
backlog with some functionalities
displayed in the example.
More granular details should be defined
in each Sprint.
There will be functional areas such Data
Warehouse, File transfers, process models
and/or general ledger that should be
included throughout the project.
These functionalities would be HL defined
during the early stage of the project and
with dependencies of the tool (T24)
capabilities and the business
requirements.

8. PRODUCT BACKLOG (&II)
Cust Web Product Backlog
Sub PO Ref Backlog Item Squad
Operations CWO - 1 As Operations Dept, the main website URL should be "www.orangebank.es" Cust
Operations CWO - 2 As Operations Dept, the system should allow sub URL for campaigns and display the main URL Cust
Operations CWO - 3 As Operations Dept, the system should keep track of sub URL when customer login Cust
Operations CWO - 4 As Operations Dept, the system should allow to display website and sub website in mobile devices Cust
Operations CWO - 5 As Operations Dept, the system should allow web responsive for multiple IOS and devices (laptop, tablet, mobile, TV..) Cust
Operations CWO - 6 As Operations Dept, the system should display a framework for content management and publicity in the main URL Cust & Ops
Logon CWL - 7 As Information Security Manager, the system should have a section to introduce a user id and password Cust
Logon CWL - 8 As Information Security Manager, the user id should be unique to each customer Cust & Ops
Logon CWL - 9 As Information Security Manager, the password should be stored in secured, encrypted and independent customer database Cust & Intr
Logon CWL - 10 As Information Security Manager, the password should be 8 characters long and allowing special characters Cust
Logon CWL - 11 As Information Security Manager, the password should expire after 6 months and website should prompt for a password change Cust
Logon CWL - 12 As Information Security Manager, the system should prompt an error in the cases of incorrect user id or password Cust
Security CWS - 13 As Information Security Manager, the system should allow only 1 session per customer and identify suspicious fraud Cust & Ops
Security CWS - 14 As Information Security Manager, the system should use fraud detection and prevention systems to identify suspicious transactions. Cust & Ops
Security CWS - 15 As Information Security Manager, Fraud detention system should allow parameterization such rules and back list of compromised or stolen cards Cust & Ops
Security CWS - 16
As Information Security Manager, Fraud detention system should monitor abnormal behaviors patterns of customer or customer devices such change of IP
address or range during open session
Cust & Ops
Security CWS - 17 As Information Security Manager, Fraud detention system should be able to detect signs of malware infection in the session such scripts behaviors. Cust & Ops
Security CWS - 18 As Information Security Manager, Fraud detention system should allow other known fraud scenarios and further development for new hacking methods Cust & Ops
Acquisitions CWA - 19 As Operations Dept, the system should allow new customer registration Cust
Acquisitions CWA - 20 As Acquisitions, the system should prompt to Acquisition website (URL to be define) Cust & Ops
The Product Backlog should contain all
requirements (PB items) which will require
further definition and details for Squads team
to develop the solution.
PB will contain functional and non functional
requirements.
Each item will be identified with unique Id for
tracking purposes and use later during the
Testing phase (UAT)
A Product Backlog item may be addressed by
different squads during its development,
therefore coordination of squads are required.
During the Sprint Planning meeting, each
Squad will discuss their involvement and plan
the resources re allocation.
Each Item should be discussed with Product
Owner for further details and
Non functional requirement may grow during
the programme.

9. Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11 Sprint 12 Sprint 13 Sprint 14
Vision & Design Cust
GO LIVE
DR1
Mock1
DR2
HL PLAN
Release
UAT 1
R UAT
2
UAT Install PROD Install
Cust Web Cust Web Cust WebCust Web
Cust Mob Cust Mob Cust Mob
Cust Ops Cust Ops Cust Ops Cust Ops Cust Ops
Cust Mob
Cust Ops Cust Ops
Dev Install
Debt Card Debt Card Debt AdquDebt Acct Debt AdquDebt Deps Debt Deps
Cust Com Cust Com Cust Com Cust Com
Cred Card Cred Card Cred Card
Cred Acct Cred Acct
Cred Loan Cred Loan
Cust Web
Cust Ops
Cust Mob
Int Rest Int Rest Int Rest Int Rest Int Rest
Int Hub Int Hub Int Hub Int Hub
Int Pay Int Pay Int Pay Int Pay
Live Proving and Pilots
Test S3.. S5 Test S6-S7 Test S8-S9 Test 10-11
Test S3-S5 Test S3-S7 Test S3-S9
Ops Dwh Ops Dwh Ops Dwh
Ops Rsk Ops Rsk Ops Rsk
Ops Dwh
Ops RR Ops RR Ops RR
Ops Dwh
Ops Rsk
Ops Dwh
Ops GL Ops GL Ops GL Ops GL Ops GL
Ops Rsk
Ops RR
Cust Com
Cust Sup
Migration Mig ReviewMigration Mig ReviewMigration Mig ReviewMigration Mig ReviewMigration
Cust Sup
Cred Sup Cred Sup Cred Sup
Ops Sup Ops Sup Ops Sup
Cred Sup
Cust Sup
Int Sup Int Sup Int Sup
Mock2
R Prod 1 R Prod 2 R Prod 3
R UAT
3
R UAT
4
Pending
Peding
Pending
Pending
The HL Plan is open and will grow and
mature throughout the programme.
There will be an initial Vision and
Design phase to High Level design the
requirements and the final solution.
This phase aims to address the initial
conversation and vision of the solution.
During the Sprints, Squads will develop and
deliver some functionalities which can be
deployed in UAT environment.
These deployments would be tested by
Product Owner and Business teams to quick
change/improve any prioritised functionality.
Ad Hoc releases can be performed as
needed.
The HL Plan contains PO and Business areas testing with current
release and previous release testing. There will be Mock events to
test migration and Dress Rehearsals to prepare the Go Live Event.
Live Proving and Pilot (aka Friends and Family) should be performed
in Production environment and be real test before Go Live.
The plan should consider to clean and dry environments for Mocks
and DR’s.
Schedule of Events should be planned for Mocks, DR and Go Live.

10. Sprint 5
Week1 Week2 Week3 Week4
SPRINT PLAN
Cust Web
Debt Card
Cred Card
Int Pay
Backlog selection
and Planning
Daily meetings
Development
Squads
Report
Daily meetings
Development
Daily meetings
Development
Daily meetings
Development
Leads meetings
Review meetings
update
update
update
update
Improve meetings
Release meeting
R
e
l
e
a
s
e
The Sprint planning would be agreed during first few
meeting in the Sprint where squads team will decide
(along with Leads) the scope from the Product Backlog
for that Sprint.
Backlog and Plan
Leads meetings
Resource re allocation
As during the sprint, some dependencies arise between squads and
functionalities, Leads plan resources accordingly to allow Squads
member to be shared between teams (see green arrows)
The Sprint planning will also contain:
• The reports schedule during the Sprint
• The Leads meeting to ensure consistency of development,
integrations and dependencies are follow up
• The Review meetings of each Squad with Product Owner
• Update of development to prepare the releasable functionalities
• Improvement meeting for each Squad and Leads to address
improvements in each and between teams (communications,
development, techniques, tool…)
• Release meeting with Leads to communicate releasable
functionalities (and report)
• Release of code on which Squads teams will deploy development.
The Sprint Planning meeting will consist in two meeting:
1.- initial meeting with all Squads members to select the backlog items
to be developed and identify any dependencies between squads
2.- meeting for Squad leads to mature and consolidate the plan and
dependencies.
Release Report
The Sprint Release will be planned between Leads and control which functionalities
are deployed and which are not from the initial Sprint Planning session.
Those functionalities not deployed will required to be included in next Planning
session and newly estimate the effort and dependencies (if any).
The Sprint Release aims to deploy code into UAT environment and is planned every
two months. It can be also be performed adhoc in case it’s needed.

11. PROGRAMME GOVERNANCE
The purpose of the Programme Governance is to ensure that decision making process is clearly articulated and that communication channels are effective.
Governance also establish the required mechanism to manage the Programme to:
Document Description
PSP Programme Sprint Plan contains all sub plans from all squads.
TCD Test Cases Document defines the test cases across workstreams
with definition of “passed”
RPP Programme Release Plan schedule the functionalities release to
Prod throughout the programme
EPP Events Programme Plan would gather all activities for Events and
Go Live
PPP Pilot Programme Plan would ensure all critical functionalities are
tested in Production environment.
Reports A set of dedicated reports to be completed within time frame
Document Description
Infrastructure
Design
Document describe the design and components of the
Infrastructure of the programme
RMD Requirements Matrix Document contains the functional and non
functional requirements
TRD Technical Specifications Document which contains the technical
details of solution.
MSD Migration Strategy document contains the strategy and scope for
the migration.
PBlog Product Backlog that gather all sub project stories and increment
deliverables.
SBlog Sprint Backlog gathers Product Backlog and Sprint planning.
Governance would include the below documentation. All documentation would be created during the whole project, updated throughout and aim to
clearly stablish the work developed.
•Ensure technical delivery is performed and aligned to business strategy
•Mitigate risks and resolve issues
•Ensure that timely decision making can be made
• Ensure timely and clear communications to stakeholders
• Provide clear escalation paths for urgent and important issues

12. Squads Programme
PROGRAMME REPORTING (I)
The purpose of the Programme Reporting is to inform, update and engage with all parties involved in the programme through a structured, clear and
consistent methodology. There are the different types, frequency and ownership:
Name Type Frequency Purpose Audience Owner Format
Steering
Committee
Forum Monthly
To provide the Steering Committee with programme updates of Sprint
outcomes; key decisions required & made; cost estimates, funding &
resourcing status; key risks & issues; escalations
Steering
Committee
Lead of
Squads
Adhoc
Report
Lead of
Squads
Meeting Weekly
To provide a weekly update of progress of all squads against Sprint
plan, deliverables and impediments, Overall RAG, resource and
financial status and risk and issues
Squads Lead
+ PO + POS
Lead of
Squads
Squads
Report
Squad
Team
Meeting Weekly
To provide a weekly update of progress against Sprint plan,
deliverables and impediments, Overall RAG, resource and financial
status and risk and issues
Squad Squad Lead
Status
Report
Daily Squad Meeting Daily
Daily meeting for each squad to share progress, impediments and
actions
Squad Squad Lead JIRA update
Review Meeting Monthly
Sprint review of each squad team and lead for identification of
releasable functionalities and review pending functionalities
Squad Squad Lead
Review
Report
Retro Meeting Monthly
Spring retrospective aims to identify improvements across working
processes, communications, tools and teams performance
Squad Squad Lead Retro report
Test
Progress
Meeting Weekly
To provide information of UAT Testing progress, testing speed, defect
identification, dependencies and fixes.
Squads + PO
+ LOS
Lead of
Squads
Testing
Report +JIRA
update
Events
Report
Commu
nication
Adhoc
To inform to Stakeholders and Programme Team of Events status, HL
plans, task and teams assignments and Event outcomes
Programme
Lead of
Squads
Adhoc
Report
Meet
Report
Report
Meet Report
SoE
The above reporting are defined and grouped to meet progress at two levels, Squads and Programme. While Squads communications have an agile approach
for better interaction, communication and progress, Programme reporting is the result of Squad meetings for Committee and Business areas be informed of
progress. Some decision from business areas and Committee may be communicated to Squads in their own terms.
Meet Report
Report
Meet

13. PROGRAMME REPORTING (& II)
Squad:
Customer Service
Status
Time
JIRA ReportSpring
Spring Progress & Review
Sprint Retro & Challenges Sprint Chart
Sprint Financials
- Cross Selling module connected to Campaign manager. Updating campaigns
- Router prompt to Cust score. Business to update score (dependency)
- New Client_Job_Salary fields to be updated (Acquisitions)
- Customer score and risk update module in progress (Score Decision)
- UX modification in progress (Business)
- Mobile display error when updating Score – in analysis
- Cust Score not updated – Business to update score decision tool with rules
- UX modification request does not fit in Sprint – Challenge PO
- Reduction of Standups due to vacation period – ensure team capacities and velocity
- Limited number of account available for test – Create new scrambled/fake accounts
Sprint 1 2 3 4 5
To Do 0 0 0 7 34
In Progress 0 3 4 18 0
DONE 16 25 29 16 0
UAT 8 3 2 0 0
Velocity 100% 90% 89% 39% 0%
Product Backlog Resources SPlan Financial
Budget 1.600.000
Current 1.439.920
Planned 1.300.000
Overrun 11%
- Increase of hours due to high rate resources used
to cover vacation period
- Expected reduction in Sprint 5 due to resources
re allocation between workstreams
- No expected increase of extra cost of
hardware/software (all licensed)
0%
10%
20%
30%
40%
0
10
20
30
40
50
S1 S2 S3 S4 S5
Each squad would create weekly reports (as example below) to communicate status, progress, issue or dependencies.
Reports template will be consistent across squads and layers. Only Review and Retro will have specific reports to ensure clarity and insight.
Reports will be reviewed in weekly basis and during Programme meetings.
GO LIVE
UAT
Date
13/XX/YY

14. RISKS & ISSUES
The Programme will ensure that squads are able to identify risks, assumptions, issues and dependencies by a RAID squad. RAID would be reviewed in
weekly basis and escalated if required.
RAID items will be gathered in unique document for all workstreams at the Squads meetings and should contain:
Risk:
• Ref
• Squad
• Title
• Raised by & date
• Description
• Likelihood & Impact
• Mitigation Actions
• Owner & Status
• Date of Review & Closed
Issues:
• Ref
• Squad
• Title
• Raised by & date
• Description
• Impact
• Actions & Date
• Owner & Status
• Date of Review & Closed
Dependencies:
• Ref
• Squad
• Title
• Description
• Dependency from
• Actions & Date
• Owner & Status
• Date of Review & Closed
Actions:
• Ref
• Squad
• Action
• Raised by & date
• Impact of no action
• Owner & Status
• Date of Review & Closed
RAID will be used in Agile approach to align and coordinate Actions, Issues and Dependencies with other squads.
Each squad will address and resolve any risk and issues in their competitive areas and raise a Sprint Backlog as response to mitigate and fix them. Still, a RAID
record should be generated.
In the case squad has dependencies with other squads, direct communication would happens in Daily meeting and assign RAID item to squad that can assist.

15. PROGRAMME TESTING (I)
Testing Phase aims to ensure all functionalities developed are delivering the Business requirements (Product Backlog).
There are two type of testing:
- Squad testing which is performed by the squad team as part of the development of functionalities. This testing would be performed in Development
environment with fake/scramble data as request.
- UAT testing. When the PO agrees the functionalities are aligned with Product Backlog and Squad had performed testing successfully, functionalities
would be release to UAT environment and PO would be able to perform testing. PO may require to be assisted by Business areas. UAT will be
performed during the project in two different phases:
- Release Testing which test the latest release of functionalities
- Smoke Testing which test the main functionalities from previous releases
The three delivery frameworks have their unique Testing approach as below:
Migration:
• Migration Review will ensure that squads have
the required data during Testing phase.
• Migration Strategy will prompt to load an initial
Data load to cover initial Sprint Test.
• Further data load will be recurrent (Mocks and
Dress Rehearsals) during project to refresh data
and cover new workstreams functionalities and
integrations.
Other Squads:
• Squads will align testing with Cust Squad and
define E2E test cases from Cust Squad.
• These may involved file transfers, REST
messaging, dwh records, financial
reconciliation, interfaces integration,
communications triggered among others.
• Integrations and Operations may be heavily
impacted due to cross testing and E2E testing.
Extra resources may be required.
• Non functional requirements will be also tested
Customer Squad:
• Squad will follow standard Agile approach for
testing and ensure product increments are
tested internally.
• Prior Release, Squads would test integrations
and dependencies to ensure functionalities
work E2E in others squads
• Cust will be main focus for Live Proving and
Pilot testing.

16. PROGRAMME TESTING (II)
A robust Test Cases frame work is require to maintain test cases throughout workstreams and capable to identify failures downstream in E2E Testing.
A definition of Passed should be agreed with PO and Business areas. These would include positive and negative test cases.
There will be various types of testing and to be performed in the each squad:
Cust Test:
• Behaviour Driven Test
• Acceptance Driven Test
• Security Test
• Component Test
Integration Test:
• Accessibility Test
• Performance Test
• Integration Test
• Technical Test
UAT:
• Functional Test
• Regression Test
• Smoke Test
• E2E Test
A mechanism to control Data quality needs to be in place to ensure Data is created (madeup) and can be provided consistently to squads teams.
Data Quality Assurance will require to control and manage all squads data requirements and identify any ETL requirement throughout the project.
Data Quality Assurance will also provide data for negative testing and prompt failure by squad request.
Migration:
• Performance Test
• Data Quality Test
• Load Test
Infra Test:
• Stability Test
• Scalability Test
• Security Test
• Load Test
Live Proving and Pilot
This test phase aims to prove that functionalities works as expected in the Production environment. These imply the following items to consider:
- E2E test cases should be passed for those functionalities in UAT. Functionalities to be tested should be agreed as MVP.
- It will be performed in Production environment which required real data, real customers and products.
- As part of the test, integration with third parties will be required such Redsys to test cards, SEPA for payments and others like insurance agencies.
- During Live Pilot, E2E cases of product lifecycle should be created from acquisitions, product usage, financial reconciliations, regulatory reporting and
in some cases, collections.
- Real data and customers are required and Product Owner would need to participate and recruit some business participants to test functionalities.
- All agreed customer functionalities (MVP) will be required to be tested and ensure non functional and business processes are aligned.
- Live Proving and Pilot will be tracked and control to ensure products viability and future customers are not impacted.
- Programme to decide

17. PROGRAMME TESTING (&III)
Hereby is an example of Test cases and dependencies:
Hereby is an example of E2E Test cases with dependencies:
Test Ref PB
Test
Number
Requirement/Story Test Case Test Description Result or DONE Passed
Phase/
Sprint
Test date Tester E2E Test Path File/REST Customer IBAN/PAN
Defect
Type
Defect
Date
Defect Description
Defect
Status
Defect
Retest
Fix
Assigned
Fix
Release
OPI-4-1 OPI-4 1 CS files are delivered to GL GL file transfer CS XXXX file is ETL to GL GL is capable to load XXXX file passed SIT
9th
Month7
Antoine WEB-GL XXXX Pepe Gil 1234567890123456
OPI-4-2 OPI-4 2 CS files are delivered to GL GL file transfer CS YYYY file is ETL to GL
GL is not capable to load YYYY
file
failed SIT
9th
Month7
Antoine WEB-GL YYYY Pepe Gil 1234567890123456 File
9th
Month10
File YYYY does not have
correct header (missing
num of records)
Open
to be
replanned
Antoine R2
CUW-12-1 CUW-12 1
Tool will allow to increase CC
limit by agent between profile
limit
Increase CC limit
Customer wants to increase
Credit Card limit to 2000
Agent capable to increase limit
requested
passed S4
10th
Month10
John
WEB-GL
WEB-DWH
XXXX Pepe Gil 1234567890123456
CUW-12-2 CUW-12 2
Tool will allow to increase CC
limit by agent between profile
limit
Increase CC limit
Customer wants to increase
Credit Card limit to 2000
Agent not capable to increase
limit due to agent profile
passed S4
10th
Month10
John WEB XXXX Pepe Gil 1234567890123456
CUW-12-3 CUW-12 3
Tool will allow to increase CC
limit by agent
Increase CC limit
Customer wants to increase
Credit Card limit to 5000
Agent capable to increase limit
due to agent profile
failed S4
10th
Month10
John
WEB-GL
WEB-Bureau
XXXX Pepe Gil 1234567890123456 Profile
10th
Month10
Agent capable to increase
CC limit when Agent CC
limit is lower than request
Open
to be
replanned
John Smith
CUW-12-4 CUW-12 4
Tool will allow to increase CC
limit by agent
Increase CC limit
Customer wants to increase
Credit Card limit to 2000
Agent not capable to increase
limit due to customer risk
failed S4
10th
Month10
John
WEB-GL
WEB-Bureau
XXXX Juan Lopez 1234567890654321 Risk
10th
Month10
Agent capable to increase
CC limit for a customer
defined as high risk
Open
to be
replanned
John Smith
CUW-12-5 CUW-12 5
Tool will allow to increase CC
limit by agent
Increase CC limit
Customer wants to increase
Credit Card limit to 2000
Agent not capable to increase
limit due to customer risk
passed S4
10th
Month10
John WEB XXXX Pepe Gil 1234567890123456
CUW-12-6 CUW-12 6
Tool will allow to increase CC
limit by agent
Increase CC limit
Customer wants to increase
Credit Card limit to 2000 AND
Campaign manager is updated
Campaign Manager updates
customer profile and assess
new campaigns
pending S4
10th
Month10
John WEB XXXX Pepe Gil 1234567890123456 Application
10th
Month10
Campaign manager not
ready to load new limits
and re assess campaign
Open
to be
replanned
To be
assigned
CUW-12-1 CUW-12 1
Customer CC Limit increase is
reflected in daily accounting
Increase CC limit Customer increase CC limit in CS CC limit increased failed UAT
11th
Month10
Luis WEB-GL XXXX Iker Diaz 1234567890112233 Profile
11th
Month10
Amount CC limit increase
is incorrectly
Open
to be
replanned
Antoine R2
CUW-12-2 CUW-12 2
Customer CC Limit increase is
reflected in daily accounting
Increase CC limit Customer increase CC limit in CS
Amount of CC limit increased
in CC Limit accounting model
passed UAT
11th
Month10
Luis WEB-GL XXXX Pepe Gil 1234567890123456
CUW-12-1 CUW-12 1
CC Limit increase is reflected in
DWH
Increase CC limit Customer increase CC limit in CS
CC increase is reflected in
DWH on submittion day
passed UAT
11th
Month10
Antoine WEB-DWH XXXX Pepe Gil 1234567890123456
Test Ref PB
Test
Number
Requirement/Story Test Case Test Description Result or DONE Passed
Phase/
Sprint
Test date Tester E2E Test Path File/REST Customer IBAN/PAN
Defect
Type
Defect
Date
Defect Description
Defect
Status
Defect
Retest
Fix
Assigned
Fix
Release
NC-FH-1 NC 1 CS files are deliveredto GL GL file transfer CS XXXX file is ETL to GL GL is capable to load XXXX file passed SIT
9th
Month7
Antoine WEB-GL XXXX Pepe Gil 1234567890123450
CS-WB-1 CS 1
Tool will allow to increase CC limitby
agent between profilelimit
Increase CC limit
Customer wants to increase Credit
Card limit to 2000
Agent capable to increase limit
requested
passed S4
10th
Month10
John WEB-GL XXXX Pepe Gil 1234567890123450
NC-GL-2 NC 2
Customer CC Limit increase is
reflectedin daily accounting
Increase CC limit Customer increase CC limitin CS
Amount of CC limitincreased in CC
Limit accountingmodel
passed UAT
11th
Month10
Luis WEB-GL XXXX Pepe Gil 1234567890123450
NC-DW-1 NC 1 CC Limit increase is reflected in DWH Increase CC limit Customer increase CC limitin CS
CC increase is reflectedin DWH on
submittion day
passed UAT
11th
Month10
Antoine WEB-DWH XXXX Pepe Gil 1234567890123450