Project Retrospective - bounswe/bounswe2026group4 GitHub Wiki

Project Retrospective

Project: Local History Story Map (StoryMap)
Group: 4
Period Covered: Beginning of semester – MVP Milestone (April 8, 2026)

Table of Contents

Overview

This page documents the team's collective reflection on the StoryMap project from the start of the semester through the MVP milestone presentation on April 8, 2026. The goal is to honestly evaluate what practices and decisions contributed positively to the project, identify what went wrong or required unplanned effort, and extract lessons that should inform the final milestone.

The team of 8 members operated as three sub-teams (frontend, backend, mobile) under a shared set of processes including GitHub issue tracking, PR-based code review, weekly full-team meetings, and wiki-based documentation throughout the semester.

What Went Well

1. Structured Planning and Scope Control

The MVP was organized as a 3-week sprint (March 15 – April 6) with an internal gate β€” the Core Implementation Complete milestone β€” set for April 2. This gate required all core features to be working end-to-end before entering the polish and deployment phase.

Before the implementation began, the team produced a detailed MVP Milestone Plan with explicit in-scope vs. deferred feature lists, a risk register, and a Definition of Done. Deferred features were documented by name with clear rationale, which kept scope stable and prevented feature creep throughout the sprint.

Impact: The project was deployed at https://storymap.page on April 3 β€” five days ahead of the submission deadline β€” leaving meaningful buffer time for testing, polishing, and demo preparation rather than firefighting last-minute integration failures.

2. PR Review Policy and Version Control Discipline

All changes followed a consistent path: GitHub issue β†’ named branch (feat/, fix/, refactor/, docs/) β†’ pull request with at least 1 required approval β†’ merge. Direct pushes to main were blocked throughout the project.

Commit messages followed a type: description convention, keeping history readable across three platforms. The review policy meant that defects were caught at the branch level before ever landing in main, reducing the need for hotfix commits late in the sprint.

Impact: Code quality remained high throughout the project. The bug fixes that were made (see What Went Wrong) were caught and resolved before they could compound, rather than accumulating into a destabilizing backlog near the deadline.

3. CI/CD Pipeline and Deployment Readiness

A GitHub Actions CI pipeline ran three parallel jobs on every push to main and on all pull requests: backend tests (against a real MySQL 8.0 service container), frontend lint and build, and mobile typecheck and tests. A separate CD pipeline handled automatic deployment to the DigitalOcean VPS on merge to main.

Docker Compose configurations (dev + prod) ensured that local development and production environments were identical. An automated Android APK build was set up via GitHub Actions, enabling consistent mobile artifact generation.

Impact: The team was able to deploy confidently because the production environment behaved the same as the development environment. Regressions from merged PRs were surfaced immediately rather than discovered during demo rehearsal.

4. Sub-Team Ownership and Parallel Progress

Splitting the team into frontend, backend, and mobile sub-teams with documented API contracts allowed all three platforms to progress in parallel without frequent blocking dependencies. Sub-team meetings were held separately from full-team meetings to allow deep technical coordination without consuming time from the full group.

Nine full-team meetings and seven sub-team meetings were held across the semester, all documented on the wiki.

Impact: Parallel development reduced bottlenecks. Frontend, mobile, and backend work progressed concurrently, and the API contract documentation meant that frontend and mobile teams could work against mocked responses while backend endpoints were still being finalized.

5. Test Coverage and Bug Detection

The team built a test suite of 1,043 tests across 90 test files and approximately 13,160 lines of test code spanning all three platforms: 569 backend tests, 363 frontend tests, and 111 mobile tests. Every feature PR was required to include corresponding tests.

The tests followed a test-pyramid strategy with unit, integration, and manual end-to-end coverage. Backend tests ran against a real MySQL database rather than mocks, catching database-specific issues (foreign key constraints, migration problems, charset handling) that in-memory substitutes would have missed.

Impact: Eight distinct bugs were caught and resolved through the test suite before the MVP presentation (see full list in the Milestone Review). These included a token refresh race condition affecting both frontend and mobile, a CORS misconfiguration blocking all frontend API calls, media file 404s, and a map pin display cap that made the map appear empty. Without systematic testing, several of these would likely have surfaced during the live demo.

6. Customer Meetings Shaping Architecture

Two customer/stakeholder meetings were held early in the semester (February 18 and February 25), before any implementation began. The feedback from these sessions directly shaped the core architecture of the platform:

  • The map interface was confirmed as a non-negotiable core element (not a secondary view)
  • Global scope was established β€” the platform should not be limited to Turkey
  • Guest read-only access was clarified as a must-have, not an enhancement
  • Time representation flexibility (exact year, decade, range, approximate period) was documented as a functional requirement
  • The community moderation approach (report-based, not pre-verification) was agreed upon

Impact: Because architectural decisions were anchored in documented customer feedback rather than internal assumptions, the team did not face a late-stage pivot where implemented features needed to be rearchitected to match stakeholder expectations. The MVP presentation received positive feedback on overall direction from the evaluator.

7. Scenarios Driving Design Continuity

Four scenarios were written during the requirements phase and used to derive use-case diagrams, class diagrams, sequence diagrams, and UI mockups. One scenario β€” the Eski Γ‡Δ±nar ParkΔ± story (Scenario 2) β€” was used directly as the narrative spine of the MVP demo, giving the design artifacts a through-line from requirements all the way to the final presentation.

Impact: The evaluator explicitly praised the scenario and world-building approach during the MVP presentation, noting that the team had understood the essence of the project. Using an existing scenario as the demo narrative also reduced preparation overhead β€” the team already had all the content and had validated the flow.

What Went Wrong or Unexpectedly

1. Implementation Compressed Into the Second Week

Despite a three-week sprint plan with weekly goals, most of the actual feature implementation was compressed into the second week. The first week moved more slowly than planned, leaving core features being built and tested during a shorter window. Thanks to our internal milestone, we had no issues with the MVP deadline, but our plan could have been followed more closely in the first week.

Root cause: Individual tasks were underestimated, and team members did not flag overloaded situations early enough for others to step in and help before the situation compounded.

Impact on lifecycle: The buffer days (April 4–6) that were explicitly reserved for integration issues and polish were partially consumed by implementation work that should have finished earlier. The team still met the deadline, but the margin for polish was smaller than planned.

Lesson: Milestone plans should include explicit check-in points mid-week (not just per-week) to catch workload imbalances early. Team members should be encouraged to surface blockers at the first sign rather than attempting to resolve them independently before raising the issue.

2. Frontend Unit Tests Not Enforced in CI During MVP

Frontend unit tests were written and ran locally throughout the sprint, but the CI pipeline did not enforce them as a required check on pull requests during the MVP phase. The frontend-checks CI job ran lint and build, but not the test suite.

Root cause: The CI job was configured to validate build correctness but the test execution step was not wired into the pipeline before the sprint began. This was identified as a gap during the sprint but was not corrected until after MVP.

Impact on lifecycle: Any frontend test regressions introduced by a PR would not have been caught automatically. While the test suite was maintained and no known regressions were silently introduced, the absence of enforcement meant that the quality gate depended on developer discipline rather than automated verification.

Fix: Frontend test enforcement in CI has been added during the MVP Reporting phase.

3. Multiple Integration Bugs Discovered Late

Several bugs surfaced during integration testing that were not caught at the unit level.

Root cause: Platform-level unit tests verify individual components in isolation but do not catch configuration gaps, missing URL patterns, or behavioral differences between platforms that only appear when the full stack is assembled.

Impact on lifecycle: All bugs were caught and resolved before the MVP presentation. However, several fixes landed within the buffer window, consuming time that had been reserved for polish. Earlier integration testing β€” before week 3 β€” would have surfaced these issues while more time was available to address them.

4. Team Restructuring Needed Due to Imbalanced Workload

Mid-sprint, Oğuz Semih Arık transferred from the backend sub-team to the mobile sub-team due to imbalanced workloads between the two groups. This decision was made proactively and documented in the project plan and further problems were prevented. In the beginning we could have estimated the workloads better and made better planning decisions to prevent this.

Fix: The transfer rebalanced the mobile team's capacity at a critical point in the sprint, preventing the mobile platform from lagging behind web and backend. It demonstrated the team's willingness to adapt structure in response to observed capacity signals rather than waiting for a problem to compound.

Impact on the Project Lifecycle

Requirements and Design Phase (February – March 14)

Customer meetings and structured elicitation questions produced a well-scoped SRS before any implementation began. The scenarios written in this phase were detailed enough to drive UML artifacts and remain useful all the way to the demo presentation. Starting implementation with clearly documented, customer-validated requirements meant the team did not need to re-elicit requirements mid-sprint to resolve ambiguity.

MVP Sprint (March 15 – April 6)

The sprint plan's internal gate (April 2) was the most consequential planning decision of the semester. By requiring that all core features be working end-to-end before entering the deployment and polish phase, the team created a forcing function that surfaced integration issues while there was still time to fix them. The gate did not eliminate integration bugs, but it moved their discovery from April 6 to April 2–3, giving the team 4–5 additional days to resolve them.

MVP Presentation (April 8, 2026)

The evaluator's feedback was positive overall. The scenario-driven demo approach was well received. The one major piece of constructive feedback β€” a strong request for a timeline feature β€” was anticipated as a deferred item and was already in the final milestone plan before the presentation.