Retrospectives - FEUP-MEIC-DS-2025-26/madeinportugal.store GitHub Wiki

Sprint #1

NOTE: please include your text here, not in a linked page, to make all text easier to reach...

T2.1.

  • What Went Well

    • Team organization and work division Tasks were divided clearly among team members, which helped avoid overlaps, reduced blockers, and made it easier for everyone to focus on their responsibilities and deliver on time.

    • Exploring different implementations The team experimented with multiple technical approaches before deciding on the final solution, which improved understanding of the problem space and increased confidence in the chosen implementation.

    • Communication with team members Day‑to‑day communication between team members worked smoothly, with people being responsive on chat and in meetings, which helped resolve doubts quickly and kept work aligned.

  • What could be improved

    • Communication with other teams Alignment with other teams was sometimes late or unclear, which caused delays and rework; next sprint, more proactive syncs and earlier clarification of dependencies are needed.

    • Meet more times with team members While communication was good, the team could benefit from more frequent short check‑ins to surface issues earlier and adjust priorities before the end of the sprint.

T2.2

  • What Went Well

    • Jumpseller integration is now fully operational.
    • The frontend migration to React was completed successfully.
    • Development pipelines were built and are functioning as intended.

  • What to improve

    • Automated tests stopped working after Jumpseller integration and need to be readjusted in the next sprint.
    • The Google Cloud deployment could not be completed before the end of the sprint and must be finalized in the next one.

  • Others

    • The information regarding Jumpseller was not publicly available, which meant we had to rely on another group and this caused delays.
    • Furthermore, we only gained access to the assessment parameters very close to the end of the sprint, as they were not communicated during lectures or practical sessions, and we only noticed their publication on Moodle at the last minute. For the next sprint, it will be essential to ask the lecturers to align their expectations with us more clearly, in order to avoid delays and ensure greater transparency and efficiency in teamwork.

T3.4

What went well?

  • The sprint backlog items were all finished.
  • The team responded effectively to challenges that arose mid‑sprint, particularly the need to integrate with the Jumpseller API.
  • The team maintained effective communication with other teams to support the integration of our service with the external services it depends on.

What should we do differently?

  • The team should engage with other teams earlier in the sprint, as communication during this sprint only began after the first third had passed.

What still puzzles me?

  • Other teams are not communicating effectively, which makes the development and integration process more difficult and less efficient.
  • The overall organization of the project across all teams has been challenging, with difficulties in aligning technology choices and ensuring smooth integration.

Project Board

Beginning of the sprint

End of the sprint

The board was refined during the sprint, which resulted in an increased number of SBIs by the end.

T5.4

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.

T7.4.

  • What Went Well

    • Tasks were more evenly spread between group members, leading to more productivity as a whole;
    • Finished polishing prototype to allow for easier development in the future;
    • Good adherence to the project's guidelines and best practices.

  • What Went Wrong

    • Communication with other teams was slow, leading to work being pushed to the next sprint;
    • Communication between some team members was a bit lacking, leading to uncertainty about progress;
    • Project components were merged late, leading to errors having to be fixed right before deployment;

  • What are we going to do to improve?

    • Schedule integrations with other teams' microservices right off the bat;
    • Improve our communication by relaying constant updates to the team members;

Sprint #2

T2.1.

  • What Went Well

    • Improved collaboration with other teams Communication with the platform and infrastructure teams was smoother compared to Sprint 1, which helped align expectations and clarify integration points.

    • GitHub Actions and automation progress Advanced the CI/CD process, improving the reliability of deployments and reducing manual steps.

    • Stable pub/sub workflow Internal pub/sub mechanisms and asynchronous communication tools worked reliably throughout the sprint, making deployments, logs and coordination smoother.

    • Independent microfrontend integration Success in deploying the microfrontend independently on MadeInPortugal.store

  • What could be improved

    • Coordination for Product Page integration Although the microfrontend is deployed on the platform, lack of synchronised timing with the Product Page prevented the component from being mounted on the actual page during the sprint.

    • Product data consistency Inconsistent handling of the shared product catalog caused unexpected issues in our microfrontend when products were removed or replaced without a clear standard. Defining a simple product-creation standard would help avoid similar problems in future sprints.

T2.2

  • What Went Well

  • What to improve

    • We faced some external communication issues and there was a lack of clarity regarding specific details on how the integration with the main website should proceed, leading to unnecessary frustration.
    • We need to streamline the integration process to avoid the "headaches" encountered during this iteration.

  • Others

    • We encountered technical setbacks beyond our control, including a GitHub Actions outage and unexpected modifications by others to the dummy products in the Jumpseller database.
    • We are preparing for the next phase, where we expect to perform further integrations with additional microservices of other teams.

T3.4

What went well?

  • The sprint backlog items were all finished.
  • The team responded effectively to the challenges, particularly in integrating with other teams’ services and managing the overall MIPS infrastructure.
  • The team maintained effective communication with other teams to support the integration of our service with the external services it depends on.

What should we do differently?

  • The team should begin working on user stories earlier. However, since the TP class is only held on Fridays, this makes the process more difficult.

What still puzzles me?

  • The problems are the same as in the last sprint:
    • Other teams are not communicating effectively, which makes the development and integration process more difficult and less efficient.
    • The overall organization of the project across all teams has been challenging, with difficulties in aligning technology choices and ensuring smooth integration.

Project Board

Beginning of the sprint

End of the sprint

T5.4

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.

T6.1.

🔄 Sprint Retrospective 6.1

Objectives for the sprint

  • Revise and optimize database structure and logic for better integration, migrating from Cloud SQL to Google's Firebase.
  • Create and share ways to publish notifications to our broker with other groups' microservices.
  • Create/Isolate logic for an email micro service and planning with other groups how to use them.

What went well ?

  • The team was able to complete all the planned work for this sprint.
  • Collaboration with other groups improved, clearer communication channels were established for how to publish notifications to the broker.
  • Organization within the team was well organized and established alternate days meetings to keep all members up to date.

What went wrong ?

  • Our notifications microservices' logic of communication using pub/sub had to be changed, from JSON to Protocol Buffers, as it was not very clear, this was the chosen format, making it harder to notify every group of the update.
  • Coordination meetings with other groups were delayed, slowing alignment on the email microservice.
  • Communication with the team developing the header was not done successfully as we weren’t able to determine which team’s interface would be used , so we had to resort to changing it directly from the MIPS Host Federation.
  • We were unable to add/run GitHub Actions for continuous Integration, as our organization’s GitHub Actions quota had already been fully consumed by other groups.

What puzzles us ?

  • Uncertainty around which teams intend to use notifications or emails.
  • What level of logging and monitoring we should expose to other teams.
  • Uncertainty about the expected throughput of the email microservice.

What are we going to do to improve?

  • Define and share a unified schema for notifications and set guidelines for all groups interacting with the broker.
  • Schedule recurring syncs with other groups to clarify notifications/email microservice requirements and avoid misalignment.

T7.4.

  • What Went Well
  • Tasks were more evenly spread between group members, leading to more productivity as a whole;
  • Pub/Sub was finished and integration with another team's work went smoothly;
  • What Went Wrong
  • Deployment still prooved difficult, many errors and bugs;
  • Github actions were non functional for a period during production;
  • Changes in how front ends should be built made our "NEXT" based front end unusable;
  • What are we going to do to improve?
  • Not leave the merge of our features to the last few days, to have more time to fix issues with the deployment;

T4.1.

  • What Went Well
  • All planned features implemented on our Product Performance Table for this sprint
  • Performed Pub/Sub implementation and also integrated with another group (The Seller/Vendor Dashboard);
  • What Went Wrong
  • Bug with the mock products does not always show after deployment
  • No CI/CD Pipeline, code not tested

What are we going to do to improve?

  • Add CI/CD Pipeline
  • Hopefully Authentication integration according to AuthCoP
  • Convert to React and integrate into MIPS-Frontend-Host-Module-Federation as described on the wiki page

Sprint #3