SDLC

1. Planning: Define the feature scope and goals.

Sprint Length: 2 Weeks
2. Gather and analyze requirements: Gather and analyze feature requirements to understand the functionalities.
Increment
Split features into user stories.
3. Design & Develop: Design and develop user stories. Day 1: Sprint Daily
4. Testing: Conduct various types of testing (unit testing, QA, and UAT) to identify and fix bugs. Planning Stand
5. Deployment: Release the feature/user stories to the production environment for end-users. Up
6. Maintenance and Support: Provide ongoing support, fix bugs, and make updates as needed.
Day 2: Backlog
Day 10: Sprint
Prioritization
6. Retrospective
1. Planning (Next Sprint)
Maintenance

Day 10: Sprint Day 5: Mid Sprint

Review Review
Retail 2. Gather and
5.
Deployment Cloud SDLC analyze
requirements
(Agile) Day 7: Backlog
Refinement

We are following the 'Release on Demand' approach, where there is no

fixed schedule (Weekly or Monthly) for releasing a feature on production
3. Design & environment. Features are released based on business demand at any
4. Testing
Develop time.
 Release Management
Decompose Add to JIRA Discuss with Estimate
Gather Add to JIRA Design & Dev unit
CR/New Requirement into User Product Prioritized Team and (Planning Assign Sprint
Requirements Sprint Backlog Develop testing
Stories Backlog Refine Poker)

QA (Dev) - CI/CD
1. After unit testing, the developer deploys to the QA environment using the CI/CD pipeline.
2. Shift the specific JIRA ticket to "Ready for QA, within Dev JIRA Board"
3. Testers will test that ticket and validate all acceptance criteria.
4. If the test passes, shift to "QA Done"; if it fails, reopen/move it back to "In Progress."

1. Testers shift QA done tickets to the Business board in the "Ready for UAT" section.
(This occurs just after QA Done to receive early feedback ; we don't wait for the sprint to close.)

UAT - CI/CD
2. The Development team then deploys these stories to UAT twice a sprint.
3. After deployment, stories in UAT shift to the "UAT Deployed" section.
4. The Business Team picks the tickets and keeps them in "UAT - In Progress," testing with the
validation of acceptance criteria.
5. Shift to the "Ready for Production" section if it passes and shift to "Failed in UAT" if it fails.
6. Developers pull back the failed ticket in the Dev Board and keep it in progress.

1. We are following the SAFe principle for production deployment - "Release on Demand."
2. We have not set a specific date for feature releases on a monthly or weekly basis.
3. Based on business requirements, we review tickets in the "Ready for Production" section
on the business board and deploy those features to the production environment.
4. Move these JIRA tickets to the "Done" section.
Production - CI/CD