Table of Content

Table of Content 1

1.0 Responsibilities 2

1.1 Technical Product Manager Responsibilities: 2

1.2 Scrum Master Responsibilities: 2

1.3 Engineers Responsibilities: 3

1.4. QA Engineer Responsibilities 3

2.0 Development Processes 3

2.1 Release Management Process 3

2.2 Sprint Management Process 8

2.3 Jira Task Documentation Process 9

2.4 Post-Production JAR Build Process 10

1.0 Responsibilities

1.1 Technical Product Manager Responsibilities:

• Gain a deep understanding of customer experience, identify and fill product gaps and generate new ideas that grow market share, improve customer experience and drive growth

• Create buy-in for the product vision both internally and with key external partners

• Ability to work well with internal teams, including developers, engineers, architects, quality assurance, and operations. Ensure requirements are fully understood and that implementation plans match expectations.

• Translate product strategy into detailed requirements and prototypes

• Scope and prioritize activities based on business and customer impact

• Understand, research, and follow technology trends in the industry and in general. Able to assess emerging products and companies to measure their potential value or threat to the company and its products, as well as make recommendations on which new technologies to invest in or leverage.

• Implement beta tests.

• Work with data pipelines, algorithms, and automated systems.

1.2 Associate Product Manager Responsibilities:

• Managing each project’s scope and timeline

• Facilitate all Scrum events, including sprint planning, daily stand-ups, sprint reviews, and sprint retrospectives.

• Work closely with the product owner to prioritize and refine the product backlog, ensuring that user stories are well-defined, estimated, and ready for development.

• Remove impediments and roadblocks that hinder the progress of the Scrum teams, fostering a collaborative and problem-solving environment.

• Monitor team metrics and key performance indicators to track progress, identify bottlenecks, and drive continuous improvement.

• Coach team members in Agile frameworks.

• Facilitate internal communication and effective collaboration.

• Help teams implement changes effectively.

• Promote a culture of transparency, trust,and open communication within and across teams.

• Stay up-to-date with industry trends and developments in Agile and Scrum methodologies, and contribute to the continuous evolution of Agile practices at Teamapt.

1.3 Engineers Responsibilities:

• Work with developers to design algorithms and flowcharts

• Produce clean, efficient code based on specifications

• Integrate software components and third-party programs

• Verify and deploy programs and systems

• Troubleshoot, debug and upgrade existing software

• Gather and evaluate user feedback

• Recommend and execute improvements

• Create technical documentation for reference and reporting

1.4. QA Engineer Responsibilities

2.0 Development Processes

2.1 Release Management Process

• Scrum Master documents future releases on JIRA before the commencement of a sprint. Each release should include;

  • Release Version

    • This follows the semantic versioning principle

      • Ex. v1.3.2 increment 1 - if there is a Major Feature, 3 - for Minor Feature and 2 - for Patch/Fix (see for detailed explanation: https://semver.org/ )

      • Releases on DCIR would be tagged according to the components affected e.g. if the frontend component is affected, the release would be tagged U.I v1.x.x. Tagging will be done by the engineer with the purview of the scrum master

      • For patches and fixes, the tagging would be done automatically by attaching the build number on Jenkins

  • Summary: 

    • Major and Minor features included in the release

    • Fixes and Patches

    • Components Affected

    • Compatible version: UI and Services

  • Description: A description of what is to be accomplished with the release

  • Approvers: 

    • QA Engineers

    • Product Managers

  • Epics, Tasks, and Bug Tickets are covered in the release.

  • Release start date: Usually sprint start date

  • Release end date: date when the binary (jar) is packaged and put on standby for onward deployment to banks.

  • Hofit fix Release process: In the situation where a hotfix needs to be released, the hotfix and any development feature or fix that is ready to be released will be added to the hotfix and released in the next release (already documented on JIRA). A new release version will be created for features/fixes still under development. 

• Environments used in the release process

  • Environments

    • Playground Environment 

      • Engineers can test their builds at this level before confirming functionality is working as expected. 

      • At this level trial and error, rnd and tinkering take place.

    • Development Environment 

      •  Quality assurance reviews for new features are undertaken within this environment.

      • It contains the latest build version of the application after QA  sign-off.  

      • Hotfixes and Platform patches are reviewed within this environment.

      • Load testing and platform optimization take place within this environment. 

    • Staging Environment

      • Replica of Production environment

      • Runs same database as bank’s live environment (MsSQL)

    • Production Environment

      • Live environment

      • Controlled access - Banks and TeamApt personnel.

    • Demo Environment

      • Ideal environment for training and presentations.

      • Depending on the release cycle, it may contain a replica of the production version.

      • Runs the most stable version of the application. 

      • Periodically updated with new features after stability.

      • May not contain the latest version.

      • To save on resources, it can be brought up or down with ease on demand.

• Repository Branching Structure in relation to environments and releases

  • Playground Environment - Any feature branch

  • Development Environment - Review-Dev

  • Demo Environment - Binary from stable release

  • Staging Environment - Main

  • Production Environment - Main

    • DD & DCIR - Bank Env

    • TPP & Switch - TeamApt Cloud

  • Each JIRA ticket should detail the respective Gitlab branch/repository - The engineer’s responsibility with Scrum Master Review. 

See Screenshot below

See flow chart below for the branching process.

Procedures in blue are performed by the Scrum Masters, while those in red are performed by the engineers. 

See flow chart below for the QA process.

2.2 Sprint Management Process

• Weekly Sprint Planning/Task Prioritization Sessions. 

  • Input:

    • Project Backlog

  • Objective:

    • To discuss priority tickets to be worked on during the sprint

  • Stakeholders: 

    • Project Managers 

    • Scrum Masters

  • Deliverables:

    • List of tasks to be completed for the sprint

    • Tickets assigned to engineers for completion

• Daily Bug Triage Sessions (15 mins) to review priority after stand up sessions. 

  • Input:

    • Newly identified issues

  • Objective:

    • To reevaluate priorities based on new discoveries

  • Stakeholders: 

    • Project Managers

    •  Scrum Masters 

    • Tech Support

  • Deliverables:

    • Updated priorities 

    • New tickets assigned to engineers for completion

• Prioritization Formula

  • High: (Added to SPRINT)

    • Production issues that impact core product function. E.g transaction processing and settlement issues. 

  • Medium (Tracked via Bank EPICS)

    • Bank customizations and integrations

  • Low (Added to SPRINT)

    • New features that provide business value and improve product usability

Notes:

If an engineer for any reason has to halt a lower priority task to focus on another task of higher priority, the engineer should indicate the task ticket the reason for pausing development and also update the block start and end dates on the ticket. 

2.3 Jira Task Documentation Process

• Product Management Process: Refer to Product Management Process Document

• Scrum Master Dev Task Documentation Process :The following links should serve as a guide on how to document development tasks by the Scrum master

  • Frontend Task Sample: ADD-457 - Getting issue details... STATUS

  • Backend API/Job Task Sample: ADD-455 - Getting issue details... STATUS

  • Database Task Sample: ADD-458 - Getting issue details... STATUS  

• QA Bug Reporting Process: Bugs discovered during testing should be reported on JIRA with the

  • A summary of the bug

  • Steps to reproduce the bug

  • Screenshot or video recording 

  • Link to affected user story

  • Link to test case 

  • Engineer, PM, and SM should be tagged in the comments after logging the bug

2.4 Post-Production JAR Build Process

Files for deployment to include:

• Jar File

• Cosmos JSON (If Management Service Change)

• Release Notes