Sprint 1 Retrospective

Overview

During sprint 1, we were able to achieve some of our goals, namely converting the frontend to React, streamlining the interface of the pricing breakdown and adding Docker for containerization, as well as Terraform for infrastructure management. We did not, however, finalize the migration from gRPC to Google Pub/Sub, which proved to be more complex than expected, and the cloud deployment still has errors that need fixing. The scale and number of these architectural changes prevented us from fully completing the payment distribution feature, and the lack of available resources related to these tools hindered our efforts. Therefore, we are delaying integrations to the next sprint.

What went well

1. Successful Architectural Foundation Work

The frontend migration to React was completed, laying the groundwork for faster UI iteration and component re-use.

The pricing breakdown interface was simplified and streamlined, improving clarity and internal consistency.

We introduced Docker for containerization and adopted Terraform for infrastructure as code, positioning us for better deployment reliability and environment parity.

These are significant infrastructure and architectural investments that move the project forward long-term, even if delivery of features slowed short-term.

2. Team Capability Expansion

The team demonstrated adaptability and willingness to adopt new technologies rapidly.

Despite limited prior exposure to parts of the new stack, foundational work was completed without blocking the sprint entirely.

3. Honest Scope Re-evaluation

The team identified early that the scale of architectural rework exceeded original capacity estimates.

A conscious decision was made to defer cross-page integration and payment distribution rollout, preventing rushed or unstable merges.

What went wrong

1. Over-ambitious Scope of Change

The sprint contained multiple deep architectural migrations at once (React, Docker, Terraform, Pub/Sub, cloud deployment), which created context switching overhead and extended ramp-up time.

Because of this expansion in technical surface area, the payment distribution feature and integration with mip.s pages could not be completed.

2. gRPC → Google Pub/Sub Migration Blocked

The migration was not completed due to unexpected complexity.

This also contributed to persistent cloud deployment errors that remain unresolved.

3. Knowledge & Resource Gaps

Lack of accessible documentation, examples, and internal familiarity with Pub/Sub, Docker deployment debugging, and Terraform configuration slowed progress.

Onboarding time was implicitly absorbed into the sprint without buffer.

4. Commit Format

Commits lacked standardization, making sprint progress harder to trace and review.

Verifiable Action Points (VAP)

• Fix cloud deployment errors

  • Verified by: One successful cloud deployment to staging with zero blocking errors, validated by logs or monitoring dashboard
  • Owner: Dev Team
  • Deadline: End of Sprint 2

• Complete gRPC to Google Pub/Sub migration

  • Verified by: Confirmed message delivery through Pub/Sub in both dev and staging, validated in application logs
  • Owner: Dev Team
  • Deadline: End of Sprint 2

• Adopt standardized commit message format

  • Verified by: 90% of commits follow the shared template
  • Owner: Entire Team

• Backlog integration work with mip.s pages

  • Verified by: New backlog items created with integration with other mip.s pages in mind for future sprint (targeting Sprint 3)
  • Owner: PO
  • Deadline: Sprint Planning Two

• Weekly meetings outside class to monitor progress

  • Verified by: Attendance by all team members
  • Owner: SM

Sprint 2 Retrospective

Overview

Sprint 2 focused heavily on addressing the architectural carry-overs from Sprint 1 and progressing with core feature integration. We successfully completed the migration from gRPC to Google Pub/Sub and implemented an internal feature integration between the breakdown widget and customization form. However, the Pub/Sub implementation still requires a fix on the mip.s frontend, and the necessity of maintaining two separate database workers (one for local development, one for cloud deployment) is a non-ideal technical debt that complicates maintenance. Due to prioritizing this infrastructure stabilization, we again had to defer the planned cross-product page integrations to Sprint 3. Furthermore, we retired one of our original backlog items (creation of templates in the customization form).

What went well

1. Resolution of Major Architectural Blocker

The complex gRPC to Google Pub/Sub migration was completed, successfully meeting the key Verifiable Action Point (VAP) from Sprint 1. This stabilizes the backend messaging architecture.

2. Internal Feature Integration Completed

The integration between the breakdown widget and the customization form was successfully completed, delivering end-to-end functionality for the core features within our team's scope.

3. Scope Reduction

We made a decision to retire the backlog item for customization form templates since the mip.s scope is now exclusively focused on food items, preventing unnecessary development effort in the next sprint.

4. Focused Prioritization

The team made a conscious, correct decision to prioritize the completion of infrastructure/architectural items (Pub/Sub migration) over integration of features, recognizing the foundational nature of the VAPs.

What went wrong

1. Cloud vs Local Configuration Split

The implementation of the Pub/Sub worker required two separate database worker versions: one using push subscriptions for Cloud Run/cloud deployment and one using pull subscriptions for local development. This introduces configuration complexity and maintenance risk, as a unified solution is preferred.

2. External Integration Block

Although our Pub/Sub migration was completed, its functionality is not fully verified on the mip.s frontend due to inadequate interference/work by other dependent groups. This makes our VAP completion technically incomplete from an end-to-end perspective.

3. Commit Format Standardization

We did not standardize the format of our commit messages once again. This should be done on sprint 3.

Verifiable Action Points (VAP)

• Unify the Pub/Sub database worker implementation

  • Goal: Eliminate the split between the local (pull) and cloud (push) subscription workers into a single, unified codebase that dynamically supports both environments.
  • Verified by: A single worker file/module handles Pub/Sub subscriptions for both local and cloud deployments, validated by successful message processing in both environments.
  • Owner: Dev Team
  • Deadline: Mid-Sprint 3

• Complete cross-page integrations

  • Goal: Integrate our features (breakdown widget and customization form) with the dependent mip.s product and product configuration pages.
  • Verified by: Successful user flow from product page to our widget, potentially validated by an integration test.
  • Owner: Dev Team
  • Deadline: End of Sprint 3

• Review and enforce Commit Format compliance

  • Goal: Ensure the team is adhering to the standardized commit message format
  • Verified by: Audit of last 20 commits shows at least 90% adherence to the shared template
  • Owner: Scrum Master
  • Deadline: Throughout Sprint 3