Sprint 5 - SwEng-UCM/P_Tactics GitHub Wiki

Documentation describing the sprint 5, done and developed between the 08/04/2025 - 22/04/2025. Included in the documentation the Sprint Planning, the Sprint Review and the Sprint Retrospective

Sprint Planning

Sprint Goal: For the fifth sprint, we are going to create the save/load command as well as a system to undo your actions, an automated player that has 3 difficulty levels, and a development in game logic (add traps, maps...)
In addition, we are aiming to refactor the GUI to make it more flexible and understandable for the user.
For sprint 5 we chose the following user stories to implement: (With same enumeration and category as in Product Backlog)

1. Story 4 - Requirements:

Description: "As a developer I want to play with an automatic player, so I can play without needing friends."
Size: Large (Around 3-4 hours).
Priority: P0 (Vital for the development).

2. Story 2 - Requirements:

Description: "As a user I want to be able to have an undo command, so I can undo my actions in case I have made an error."
Size: Medium(Around 2-3 hours).
Priority: P0 (Vital for the development).

3. Story 3 - Requirements:

Description: "As a user I want to be able to have a redo command, so I can redo my actions in case I have made an error."
Size: Medium(Around 2-3 hours).
Priority: P0 (Vital for the development).

4. Story 4 - Requirements:

Description: "As a user I want to be able to save/load my games, so I can continue playing later."
Size: Small (Less than 2 hours).
Priority: P0 (Vital for the development).

5. Story 3 - Objectives:

Description: "As a user I want to win by reaching a key tile (in case of continuous stalemate)."
Size: Small (Less than 2 hours).
Priority: P0 (Vital for the development).

6. Story 5 - GUI:

Description: "As a user I want the map to include different interactables in order to make the game more interesting."
Size: Small (Around 2-3 hours).
Priority: P2 (Needed for the development).

Sprint Review

All proposed objectives have been solidly implemented and the sprint goal was definitely achieved. Overall it has been perhaps the most productive sprint to the date (also the longest). We have focused on progressing the code and implementing new features while ignoring some bugs and inefficiencies leftover from previous sprints. Mostly, the effort was dedicated towards building to fulfill the criteria of the project.

Sprint Retrospective

What went well during the sprint?

Organization and overall work/productiveness. The task distribution has allowed everyone to work on a distinct task without much overlapping but still maintaining communication to avoid any major problems.

What went wrong during the sprint?

With everyone doing a distinct task, however, has come a slight lack of code review. So the maintenance of the code has downgraded a bit, choosing to ignore some bugs for the benefit of quick progress.

What can we learn and improve for the next sprint?

For the next sprint, since most core features have been implemented, we will be maintaining a distinct separation of tasks, as it has worked very well. However, we will be focusing on repairing, improving and optimizing our existing code, we will also work on establishing better systems to ensure better code maintenance for the next time.