Sprint Retrospective — Sprint 1

Planned PBIs

• Delivery options integration
• Pickup point selection logic
• Shipping address management improvements
• Initial deployment setup for delivery-related features

Status:
Core features were fully implemented and tested locally, but deployment to shared/staging environments was not completed.

---

What Went Well

1. Strong Development Pace

The team implemented and validated assigned features quickly. Local development went smoothly thanks to prior groundwork and clear internal division of tasks.

2. High Code Quality

• Stable local builds
• Good testing discipline before handoff

3. Good Internal Communication

Team communication during development was effective, with rapid alignment on technical decisions and quick resolution of internal blockers.

4. Smooth Feature Integration (Locally)

Delivery methods, pickup point logic, and address management were integrated cleanly in the local environment, with minimal merge conflicts.

---

What Didn’t Go Well

1. Deployment Bottlenecks

Although development was completed quickly, the team was unable to properly deploy due to:

• unclear ownership of the deployment pipeline
• limited access to required environments
• dependency on other teams to trigger or review deployment steps

2. Cross-Team Communication Gaps

Coordination with other teams (responsible for infra, API, or deployment review) was slow, resulting in:

• waiting times for responses
• uncertainty about who was responsible for what
• misalignment between development readiness and deployment scheduling

---

What Is Still a Problem

1. Unclear Deployment Responsibilities

It is still not fully defined who triggers deployments, who approves them, and how teams should coordinate them.

2. Staging Environment Synchronization

Staging is not consistently aligned with the state of development, causing uncertainty about when features can be tested collaboratively.

4. Limited Feature Depth

Although the work delivered this sprint is high quality and stable, some features could have been expanded further in depth and completeness.
With smoother cross-team coordination, we would have had the opportunity to refine and enhance these features beyond their initial functional scope.

---

Lessons Learned

Early Coordination Is Critical

Even if development goes smoothly, late-stage blockers can prevent delivery. Dependencies and contact points must be identified earlier in the sprint.

---

Overall Summary

This sprint demonstrated excellent delivery capability from the team, with rapid and high-quality development of planned features.
However, deployment readiness was significantly impacted by communication gaps and unclear responsibilities across teams, which also limited our ability to deepen certain features.

By improving documentation, coordination, and cross-team communication, the team will be better positioned to deliver work predictably and reduce friction in future sprints. This will allow the team’s strong development performance to translate into successful, end-to-end delivery.

Sprint Retrospective — Sprint 2

Status:

Core features were fully implemented and tested. The team successfully overcame the process blockers from Sprint 1, but the deployment to production was blocked at the end of the cycle due to infrastructure/cost limits, and some delivered features still require refinement.

---

What Went Well

1. Improved Deployment Coordination (Process)

   The team proactively identified and engaged the process-owning team earlier, allowing code integration into the pipeline to proceed more clearly and with monitoring access.

2. Sustained Development Quality

   Code quality remained high, with stable builds and good local testing practices maintained throughout the sprint.

3. Delivery Readiness (Code Perspective)

   The team successfully developed code that was ready for deployment, confirming the strong internal development capacity.

---

What Didn’t Go Well

1. Deployment Blocked by GitHub Credit Limit

   The final deployment to production was prevented because the GitHub account ran out of minutes/credits for the GitHub Actions runners.

2. Limited Feature Depth and Scope

   The intense focus on resolving deployment issues (both process and infrastructure) consumed time that should have been dedicated to feature refinement, resulting in delivered features that, while functional, lack greater depth.

---

What Is Still a Problem

1. Feature Refinement Priority

   The need to deepen and refine the delivered functionalities remains critical. The focus needs to shift from "just delivering" to "delivering completely."

2. Technical Debt Management

   An explicit plan is needed to address the technical debt created this sprint, ensuring it does not become a future roadblock.

---

Lessons Learned

The team resolved the communication and process barriers from Sprint 1.

---

Overall Summary

Sprint 2 demonstrated excellent progression, confirming the team's high development capability and the successful overcoming of the inter-team process challenges from the previous sprint. However, delivery was once again compromised by an external factor: the GitHub credit limitation.

The focus for the next sprint must be: Direct development efforts toward deepening the features already delivered** and resolving the accumulated technical debt.