Project/Product Development Procedure

1. Purpose #

1.1 This procedure establishes the formal process for the development and continuous monitoring of approved projects and products. Its purpose is to define a standardized Agile development methodology that ensures code quality, promotes collaboration, maintains project visibility, and guarantees a smooth, continuous delivery of a robust and scalable solution.

2. Scope of Application #

2.1 This procedure applies to all development and monitoring activities for projects and products that have received final approval from the Project / Product Design Procedure (BM-TD-P-25-003) and have a finalized Planning Document. It covers all tasks from sprint execution to code deployment and ongoing monitoring.

3. Definition #

3.1 Development Phase: The period of a project’s lifecycle dedicated to writing code, building features, and creating the functional product.
3.2 Sprint Execution: The process of a development team working on tasks from the sprint backlog during a fixed-length sprint.
3.3 Daily Stand-up: A daily brainstorm session is held to report on progress, identify any blockers, and coordinate efforts.
3.4 Code Review: A systematic examination of source code by peers to find and fix mistakes, improve code quality, and ensure adherence to standards.
3.5 Version Control: The practice of tracking and managing changes to software code using a system like Git.
3.6 CI/CD (Continuous Integration/Continuous Delivery): An automated pipeline that builds, tests, and prepares code changes for deployment.
3.7 Pull Request: A formal request to merge a set of code changes from one branch of a version control system into another, serving as a collaborative tool for code review and discussion before integration. 3.8 Bug Fix: A small code change to correct an issue or defect in the software. 3.9 Change Request: A formal request to add, modify, or remove features from the original scope of the project. 3.10 Sprint Review: A meeting held at the end of a sprint to demonstrate completed work to stakeholders. 3.11 Sprint Retrospective: A brainstorm session at the end of a sprint for the team to reflect on what went well, what could be improved, and to create an action plan for the next sprint. 3.12 UAT (User Acceptance Testing): Formal testing by business stakeholders or end-users to confirm that the product meets their requirements. 3.13 Jira: The project management tool used for sprint management, issue tracking, and backlog management. 3.14 Code Quality Standards: A set of rules and guidelines that all code must follow, encompassing maintainability, readability, security, and performance. This includes adherence to principles such as SOLID, DRY, and YAGNI, as well as specific language style guides like PEP 8 for Python. 3.15 Development Stage: The environment where code is written and tested by developers. It is a local, isolated environment not accessible to other teams. 3.16 Staging Stage: A replica of the production environment used for final testing and quality assurance before a product is released. It is used for comprehensive testing by developers and business stakeholders. 3.17 Production Stage: The live, user-facing environment where the final product is hosted and used by customers. 3.18 Testing: The process of executing a program with the intent of finding errors. This procedure uses several types of testing:- 1. User Acceptance Testing (UAT): Final validation by business stakeholders that the product meets requirements. 2. Unit Testing: Checks individual components of the code in isolation. 3. Functional Testing: Verifies a feature’s functionality from a user’s perspective. 4. Integration Testing: Confirms that different modules work together correctly. 5. Regression Testing: Ensures new changes haven’t broken existing functionality. 6. Automated Testing: Tests run automatically as part of the CI/CD pipeline.

4. Responsibility #

4.1 Developers
4.1.1 Implements features and functionalities as defined in the sprint backlog.
4.1.2 Adheres to established coding standards and best practices.
4.1.3 Participates in daily stand-ups, code reviews, and sprint ceremonies. 4.1.4 Tracks and updates progress on assigned tasks in Jira. 4.1.5. Develops and executes comprehensive test plans and test cases for their work, including unit, functional, integration, and regression tests. 4.1.6 Performs functional, integration, and regression testing on the staging environment.
4.2  Technology Department
4.2.1 Owns and drives the technical direction of the project, including managing the version control system and CI/CD pipeline.
4.2.2 Facilitates sprint planning, daily stand-ups, and sprint retrospectives.
4.2.3 Acts as the primary point of contact for technical queries during the development phase.
4.2.4 Manages and maintains the production and staging infrastructure. 4.2.5 Is responsible for the deployment of the final product. 4.2.6 Conducts a thorough code review using the Code Review Checklist (7.1). The review focuses on quality, adherence to standards, security, and performance. 4.2.7 Provides initial incident response for critical issues.
4.3 IT Operational Manager
4.3.1 Manages the sprint backlog by prioritizing tasks and user stories.
4.3.2 Ensures communication and alignment between the development team and business stakeholders. 4.3.3 Oversees the entire development process, ensuring it aligns with the project plan and technical strategy. 4.3.4 Provides final approval for major feature deployments and infrastructure changes. 4.3.5 Owns the overall project delivery and strategic alignment. 4.3.6 Gathers new feature requests and change requests from the Business Development Department for review and prioritization. 4.3.7 Resolves impediments and escalations that cannot be handled by the Project Lead.
4.4 Business Development Department
4.4.1 Participates in sprint review meetings to provide feedback on completed work also participates in User Acceptance Testing (UAT) to validate the product meets business requirements.
4.5 Creative & Design Department
4.5.1 Provides support to developers on design implementation, ensuring the final product matches the approved mockups and prototypes. 4.5.2 Reviews implemented features during the development to provide early feedback on UI/UX adherence.

5. Work flow #

5.1 Sprint Planning & Backlog assigning
5.1.1 The IT Operational Manager, with input from the team and Business Development, reviews and refines the sprint backlog in Jira, ensuring all tasks are clearly defined and estimated.
5.1.2 The team commits to completing a specific set of tasks for the upcoming sprint. 5.1.3 The Technology and Finance departments will coordinate on the budget allocation for each sprint to ensure financial transparency.
5.2 Sprint Execution & Daily Stand-ups
5.2.1 The development team works on assigned tasks from the sprint backlog.
5.2.2 A daily brainstorm session is held to report on progress, identify any blockers, and coordinate efforts.
5.2.3 All task progress is updated in real-time in Jira. 5.2.4 All sprint ceremonies and key meetings will be formally documented using the Meeting Minutes Procedure to ensure a clear record of decisions, action items, and resolutions.
5.3 Setup
5.3.1 The technical lead sets up all necessary development environments, including local environments for individual developers and a shared staging environment.
5.3.2 The version control repository (Git) is configured with branches for features, development, and the main branch, along with the automated CI/CD pipeline. 5.3.3 Necessary APIs, databases, and third-party services are configured in the staging environment for testing and review.
5.4 Development & Code Review
5.4.1 Developers write clean, well-commented code according to established coding standards and the project’s technical plan.
5.4.2 Once a feature or task is complete, the developer creates a pull request in the version control system (e.g., Git). 5.4.3 The Senior Developer conducts a thorough code review using the Code Review Checklist (7.1). The review focuses on quality, adherence to standards, security, and performance. 5.4.4 .All review comments must be addressed and approved by the reviewer before the code is merged. 5.4.5 Final approval for merging the code into the main branch is provided by the IT Operational Manager.
5.5 Continuous Integration & Testing
5.5.1 The merged code is automatically built and tested via the CI/CD pipeline, including unit and integration tests.
5.5.2 A staging environment is deployed for dedicated testing by the development team and review by other stakeholders. 5.5.3 The developers, as part of the QA process, perform thorough testing based on pre-defined test cases, logging any bugs or issues in Jira for the development team to fix.
5.6 Sprint Review & UAT
5.6.1 At the end of each sprint, a Sprint Review meeting is held to demonstrate the completed features to Business Development and other stakeholders. This meeting will be scheduled within 1-2 business days of the sprint’s completion.
5.6.2 This meeting serves as a preliminary User Acceptance Testing (UAT), where Business Development validates that the features meet their original requirements.
5.6.3 A Sprint Retrospective is held internally for the team to reflect on the sprint’s performance and plan for improvements. 5.6.4 All feedback and decisions from this meeting are documented in meeting minutes using the Meeting Minutes Procedure.

6. Generating records #

6.1 << Jira Sprint Summaries>> 6.2 << Meeting minute>>

7. Reference documents #

7.1 <<BM-TD-P-25-002-01A Project/product plan: A form to formally obtain and record stakeholder approval on project plan.>>

8. Relevant documents #

8.1 <<BM-TD-P-25-003 Project / Product Design Procedure>> 8.2 <<BM-TD-P-25-002 Project / Product Planning Procedure>>

9. Flow chart #

Updated on November 25, 2025