Before anything With this link, while using a Concordia University account, you can view the Excel sheet that has every Sprint Summary table made during the development of this project.

Sprint Summary - Sprint 1

Sprint 1 focused on setting up the structure and the tools for our project. In order to do so, the team has set up the developing environment, organized the documentation in the Github Wiki and planning out our next Sprint.

During this Sprint, we faced some challenges after meeting with the Product Owner. They set a list of changes we needed to work on to meet their expectations, which required a discussion with the team and some follow up questions with them. With the limited time left in the Sprint after the Product Owner meeting, our team had to work hard and fast to meet their expectations.

Tasks and Story Point Allocation

Due to this sprint being focused on setup, Sprint 1 is composed of infrastructure tasks. The following table shows the infra-tasks and the story points allocated to each task.

Burndown Chart

This burndown chart represents the progress of remaining story points over time throughout Sprint 1.

This Sprint spanned over two weeks, from January 12 2026 to January 25 2026.

Velocity

For this Sprint, we have planned to accomplish 20 Story Points where most were related to infrastructure tasks.

At the end of the Sprint, we have accomplished all 20 Story Points, meaning our velocity was fantastic for this Sprint and we should keep it like that.

Contrarily to the slope shown by the burndown chart, our plan for this Sprint was executed really well. In reality, the "open" line should be closer to the ideal line, but due to the repository still being fully set up to meet the proper standards at the beginning, the Github Issues could not be closed at their completion date.

Sprint 1 Retrospective

Full team retrospective discussion available here

Keep doing

• Good communication between team members
• Being proactive and helping each other out
• Having momentum and meeting sprint deadlines

Start doing

• Fixed weekly meetings of maximum 30mins (Saturdays after 6pm)
• Roles for the concerned people to be tagged on the team's discord
• Organizing into front/backend teams for short/focused meetings
• Only assign PRs to those that are concerned
• Creating and assigning issues earlier in the sprint
• Creating Threads in Discord for short term discussion

Stop doing

• Scheduling many meetings with the whole team
• Spreading important updates across unrelated Discord channels
• Leaving story points and reviews until the end of the sprint
• Relying on implicit ownership (assuming "someone else will review it")

Do more of

• Using structured communication (dedicated channels, threads, pinned messages)
• Keeping track on status of current Issues on github
• Sub-team coordination and manager-level (Rym and Mauricio) syncs
• Writing directly and clearly in shared documentation

Do less of

• Overloading everyone with information that’s not relevant to their role
• Context-switching across too many Discord messages and channels
• Delaying feedback and reviews when tasks are completed

Action Items

• Schedule fixed weekly sync (30mmins max Saturdays after 6pm)
• Reduce all-hands meetings by adding sub-team meetings and minimized full-team meetings
• Use Discord Threads for focused discussions
• Post key updates in designated channels only
• Pin critical messages
• Tag responsible roles and avoid "FYI for everyone"
• Define PRs explicitly
• Assign PRs to relevant reviewers

Sprint Summary - Sprint 2

Sprint 2 was focused on implementing the features of Epic #1. Before the start of the sprint, we did a meeting to add estimated Story Points to the issues and we assigned people to them.

During this Sprint, tasks were properly being completed, but we ran into organization/planning issues. Despite prior planning, some of us were uncertain of the tasks we had to accomplish during the Sprint, which lead to some slight delays. A reunion during the weekend was required to fix this problem.

In the second half of the Sprint, 3 team members went to a competition and were unavailable for that time. We were shorter on hands, but they completed their task and communicated with the rest of the team before leaving.

During the PO meeting, the product owner pointed out a discrepancy between an app requirement and a developing app feature, where he requested changes. Instead of highlighting the Concordia building nearest to the user, it was required to highlight the Concordia building the user is currently in if he is in one. Due to the lack of time, the delivery of the feature was pushed to the next Sprint.

Tests were developed late, due to the people we gave the task to needing to wait for the features to be delivered and the unfamiliarity with the technology. To resolve this issue, we plan on delivering tests alongside the features for future Sprints.

Tasks and Story Point Allocation

The following table illustrates the tasks and the Story Points we assigned to them for the sprint. It also shows their status at the end of the Sprint.

Burndown Chart

This burndown chart represents the progress of remaining story points over time throughout Sprint 2.

This Sprint spanned over two weeks, from January 26 2026 to February 8 2026.

Velocity

During Sprint 2, we had a total of 35 Story points and we completed 27.

Our velocity was good this sprint and overall was planned well. We however seemed to have overestimated our tasks near the end of the Sprint.

Notable areas on the chart are the following:

1- The small spike at the start was due to adding a task (Set up SonarQube) during the sprint that was not initially documented at the start of the sprint.

2- The huge drop is the completion of 2 major tasks (Load and render SGW + Loyola Campus (10 SP)) Their completion initiated the start of the next tasks

3- The end shows incomplete tasks. A feature (Nearest building) needed to be refactored (Requested by PO) due to it not being exactly like the project requirements. It was pushed to next sprint. Also, we added some story points to some acceptance tests as requested by the PO, which explains the spike at the end. We were not able to finish all of them in time.

Sprint 2 Retrospective

Full team retrospective discussion available here

Keep doing

• Mentioning the specific people with an @ that will reviewing a given pr
• Working together to solve difficult bugs
• In-depth reviews of PRs
• Fixed weekly meetings of maximum 30mins (Saturdays after 6pm)
• Creating Threads in Discord for short term discussion
• Not context-switching across too many Discord messages and channels

Start doing

• Setting reminders for team meetings
• Updating sub-team managers on what we are working on so nothing is forgotten
• Properly reporting bugs with the correct github issues template

Stop doing

• Leaving too much work for the last few days of the sprint
• Not responding to any messages for many days
• Leaving testing on the backburner
• Leaving Wiki documentation to the end

Do more of

• Asking for clarifications from the PO earlier on
• Smaller sub-team meetings to know what is going on
• Making sure people know what to work on next
• Keeping on top of documentation requirements

Do less of

• Trying to merge PRs with small mistakes since it is easier
• Forgetting to resolve comments on PRs which delays merging even more

Action Items

• Have a dedicated updates channel for people to post progress
• Add unit testing to every PR, so we don't leave it to the end
• Set a reminder for 24h in advance of a team meeting
• Start daily text checkups to make sure people have a task that they can work on
• Create a reminders channel specifically for meeting reminders
• Add [Refactoring] tags to commits for easier documentation of them
• Start reporting bugs with github issues

Sprint Summary - Sprint 3

For Sprint 3, the team's plan was to tackle and implement the tasks related to Epic 2 (Outdoor Directions).

During this Sprint, we had severe planning problems, so we did not complete many tasks. We heavily overestimated the weight of the school workload during the midterm period, which resulted in many of us having no time to focus on the project. We were forced to push our tasks to the next sprint and to rely on the upcoming reading week to double our efforts. All of these issues were made known to the PO during the meeting.

Tasks and Story Point Allocation

The following table illustrates the tasks and the Story Points we assigned to them for the sprint. It also shows their status at the end of the Sprint.

Burndown Chart

This burndown chart represents the progress of remaining story points over time throughout Sprint 3.

This Sprint spanned over two weeks, from February 8 2026 to February 22 2026.

Velocity

During this sprint, we performed at a terrible velocity. We completed 6 user story points out of a total of 46, leaving us with 40 story points to push to the next sprint. We have severely overestimated the amount of tasks we could complete during midterm season and we hope to resolve this in this next sprint since we will have the reading week.

A notable part on our graph, other than the task overestimation, is the spike seen near the start of the sprint. We have forgotten to add story points to our acceptance tests at the start of the sprint.

Sprint 3 Retrospective

Full team retrospective discussion available here

Keep doing

• Mentioning the specific people with an @ that will reviewing a given pr
• Working together to solve difficult bugs
• In-depth reviews of PRs
• Fixed weekly meetings of maximum 30mins (Saturdays after 6pm)
• Creating Threads in Discord for short term discussion
• Not context-switching across too many Discord messages and channels
• Setting reminders for team meetings
• Properly reporting bugs with the correct github issues template
• Keeping on top of documentation requirements
• Using [Refactoring] tags to commits for easier documentation of them

Start doing

• Updating sub-team managers on what we are working on so nothing is forgotten
• Taking into consideration other life events when planning the sprints
• Start showing which tasks block others

Stop doing

• Leaving too much work for the last few days of the sprint
• Not responding to any messages for many days

Do more of

• Adding to the wiki throughout the sprint
• Asking for clarifications from the PO earlier on
• Smaller sub-team meetings to know what is going on
• Making sure people know what to work on next
• Using the sprint planning channels that we had previously
• Giving more UI/UX feedback earlier

Do less of

• Waiting for other tasks to be fully complete before starting on others
• Disregarding the UI mockups when implementing features

Action Items

• Have a dedicated updates channel for people to post progress
• Start daily text checkups to make sure people have a task that they can work on
• Have a schedule of everyone's upcoming deadlines to plan around them
• Create a task concurrency breakdown

Sprint Summary - Sprint 4

For Sprint 4, the team's plan was to catch up on our unfinished Epic 2 tasks and tackle Epic 3 at the same time.

During this Sprint, near the start, we had some small organization issues due to midterms so we had an initial slow pace. We overestimated our planned tasks this Sprint, but a lot of progress was done. Although we still pushed many tasks to the next Sprint, a huge amount of them are almost complete or are nearly 100% finished and under active review in a pull request.

Tasks and Story Point Allocation

The following table illustrates the tasks and the Story Points we assigned to them for the sprint. It also shows their status at the end of the Sprint.

Burndown Chart

This burndown chart represents the progress of remaining story points over time throughout Sprint 4.

This Sprint spanned over two weeks, from February 23 2026 to March 8th 2026.

Velocity

During this sprint, we performed at a not so good, but acceptable velocity considering we had almost had 2 entire sprints worth of User Story Points. We completed 26 user story points out of a total of 68, leaving us with 42 story points to push to the next sprint.

We have overestimated the amount of tasks we could complete for this sprint. However, It is not as bad as last Sprint, due to us actually having most of the unfinished features in pull requests that are actively being reviewed and refined. Some of those pull requests can close 5 to 8 story points by themselves.

A notable part on our graph is the constant line at the beginning. The burndown chart shows inactivity for the first few days, however, features were worked on and even finished and under review in a pull request. However, since a lot of us still had midterms, proper reviews for certain pull requests took a long time to be done.

Sprint 4 Retrospective

Full team retrospective discussion available here

Keep doing

• In-depth reviews of PRs
• Keeping everybody up-to-date with what you are doing each day
• Making sure people know what to work on next
• Testing everything that we push with various unit/integration tests
• Coordinating tasks and delegating when blocked/unable to work
• Maintaining our higher velocity
• Using the sprint planning channels that we had previously
• Giving more UI/UX feedback earlier
• Not waiting for other tasks to be fully complete before starting on others

Start doing

• Clarifying requirements with the PO earlier and more frequently
• Splitting large tasks into smaller ones that can be completed in parallel
• Completing blocking tasks earlier rather than later
• Adding more descriptions of what is expected for each task/issue
• Tagging reviewers and checking PR statuses daily

Stop doing

• Leaving PRs open for a long time
• Having issues without a clear description
• Leaving large tasks for later in the sprint

Do more of

• Adding to the wiki throughout the sprint
• Asking for clarifications from the PO earlier
• Proper regression testing to catch breaking features

Do less of

• Accidentally breaking features during merge conflicts

Action Items

• Split ATs into E2E tests (with story points) and what the PO signs
• Review PRs within 12 hours of opening and tag the reviewers to remind them
• Break large tasks into smaller ones
• Set clearer roadmap timelines

Sprint Summary - Sprint 5

Tasks and Story Point Allocation

The following tables illustrates the tasks and the Story Points we assigned to them for the sprint. It also shows their status at the end of the Sprint.

Burndown Chart

This burndown chart represents the progress of remaining story points over time throughout Sprint 5.

Velocity

During this sprint, we have planned a grand total of 85 story points, and we have completed 46 story points. The burndown chart illustrates slow velocity, but we have accomplished all the big features that blocked many other small tasks from progressing (indicated by the sprint summary tables). We have many 1 and 2 value issues that can now be tackled simultaneously without (or almost) any blockers. Velocity might have been slow, but the gained value is really high. Going forward, even with the addition of next sprint's features, we should be able to tackle the remaining tasks at a high velocity.

Sprint 5 Retrospective

Full team retrospective discussion available here

Keep doing

• Strong team communication and regular updates via channels
• Collaborative discussions and helping each other with implementation decisions
• Keeping everyone informed about who is doing what and who is available
• Providing early feedback (especially on UI/UX when possible)
• Splitting ATs into E2E tests (with story points) and what the PO signs
• Testing everything that we push with various unit/integration tests
• Coordinating tasks and delegating when blocked/unable to work
• Using the sprint planning channels that we had previously
• Not waiting for other tasks to be fully complete before starting on others
• Clarifying requirements with the PO earlier and more frequently
• Adding more descriptions of what is expected for each task/issue

Start doing

• Setting clear start dates, deadlines, and expectations for tasks
• Reviewing PRs and responding to feedback on the same day
• Defining task requirements and acceptance criteria more clearly upfront
• Ensuring PRs are fully tested and complete before requesting review
• Planning around dependencies to avoid blocked or idle team members

Stop doing

• Leaving PRs open for extended periods (multiple days or weeks)
• Delaying responses during PR review cycles (causing long back-and-forth)
• Working on tasks without clear scope or expectations
• Letting blocking tasks stall overall team progress

Do more of

• Working in parallel even while blocked
• Prioritizing and completing blocking tasks early
• Tagging reviewers and checking PR statuses daily
• Adding to the wiki throughout the sprint

Do less of

• Spending too much time at the start of the sprint not doing enough work
• Letting morale drops decrease productivity

Action Items

• Review PRs within same day (or max 24h) and act on feedback immediately or communicate if that is not possible
• Set a time limit for PRs (e.g., no PR open > 2–3 days without action)
• Break large tasks into smaller, well-defined units with clear ownership
• Add start/end dates and deadlines to all tasks
• Ensure PRs meet checklist requirements and are fully tested before submission
• Prioritize and complete blocking features first
• Improve sprint planning by staying aware of dependencies
• Do smaller, incremental PR review passes instead of large delayed ones

Sprint Summary - Sprint 6

Tasks and Story Point Allocation

The following tables illustrates the tasks and the Story Points we assigned to them for the sprint. It also shows their status at the end of the Sprint.

Burndown Chart

This burndown chart represents the progress of remaining story points over time throughout Sprint 6.

Velocity

During this sprint, we have planned a grand total of 50 story points split into 27 issues, and we have completed all 50 story points :tada:. The burndown chart illustrates a good velocity, we started the sprint really strong, but we seemed to have overestimated some of the tasks near the halfway mark of the sprint. The tasks were bigger and more complex, and it required extensive development time. Regardless, we made sure to stay near the ideal line.

Despite the slowed down pace, by the end of the sprint, we completed every task required by the project's scope and their associated E2E tests. We are proud to announce that our project is complete. 👍

Sprint 6 Retrospective

Full team retrospective discussion available here

Keep doing

• Fast and efficient PR reviews
• Strong and consistent team communication
• Working in parallel on tasks
• High sprint velocity and productivity
• Early handling of blocking/important tasks
• Clear task distribution (when done well)
• Quick responsiveness during collaboration

Start doing

• Involve everyone in sprint planning
• Assign tasks based on individual strengths and expertise
• Break down large tasks (5+ points) into smaller ones
• Add tags/labels to tasks for clarity and ownership
• Establish a shared schedule/timeline for deliverables
• Improve communication visibility (avoid lost messages)
• Plan sprints more realistically (not overload them)

Stop doing

• Leaving too many tasks for the last sprints
• Overloading sprints with unrealistic workloads
• Creating designs/mockups without clear validated logic
• Inconsistent updates (e.g., Wiki, status channels)

Do more of

• Early progress at the start of the sprint
• Collaboration and quick feedback loops
• Parallel development across team members
• Clear communication of status and expectations
• Maintaining strong momentum throughout the sprint
• Reviewing and merging PRs quickly

Do less of

• Delayed PR reviews
• Poor or inconsistent documentation updates (Wiki)
• Weak planning or last-minute task accumulation
• Communication gaps due to notification overload
• Context switching caused by unclear priorities
• Spending time on work that may be scrapped later

Action Items

• Include all team members in sprint planning sessions
• Break large tasks into smaller, manageable units
• Assign tasks aligned with team members’ strengths
• Use tags/labels for better task categorization
• Set realistic sprint goals and limit scope
• Improve documentation update consistency
• Maintain regular and visible communication updates