Sprint Retrospectives 6.1 - FEUP-MEIC-DS-2025-26/madeinportugal.store GitHub Wiki
Sprint 1
🔄 Sprint Retrospective
What went well ?
The team was able to complete almost all the planned work for this sprint.
Collaboration and communication within the team remained strong, helping us move tasks forward efficiently.
Our microservice is already running on the cloud and can be accessed by every team if they need to test integration with it.
What went wrong ?
There was a slight delay in some tasks due to the need to restructure our architecture.
Adjusting our system to align with Google Pub/Sub’s recommendations took more time than initially anticipated.
What puzzles us ?
How we can better estimate the time required for architectural changes in future sprints.
How to coordinate with other teams more efficiently to integrate our microservice with theirs.
How to use Google Pub/Sub’s topic-publishing features to provide other groups with access to our topics in a systematic and simple way.
What are we going to do to improve?
Allocate time for integrations with other teams' microservices.
Review and refine our estimation process to account for potential restructuring or unexpected dependencies.
😊 Happiness Meters:
Sprint 2
🔄 Sprint Retrospective
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.