Using all the feedback and testing that you have done in Sprint 1, have a good long think about how you are going to move forward over the next sprint.
As a team you should analyse your Trello board and adjust your plan now. Add or remove tasks from your board. Make sure you have prioritized the next set of tasks for this sprint.
It is OK to pivot. That is why the project management methodology we are using is called "Agile"
Fill out the Sprint 2 Planning Section of your Development Log now!
Just like before, it is time to review our feedback, record our progress, and reflect on how well—or poorly—the build has gone so far.
At this stage, the core hardware subsystems of your project should be functional. The last sprint is NOT the time to be adding complex new mechanics. If you haven't implemented that advanced robotic arm or complex vision sensor by now, be honest with yourself: it’s likely not going to happen in the remaining time.
Pivot now. Scrap the unfinished "nice-to-have" features so you can concentrate on refining and polishing the core systems you already have working. Also remember you are building the robot to compete in a competition. Consider making these changes:
Change chassis to be smaller
Make sure your battery lasts the longest
Make sure your esp32 works consistently (focus on testing aspect)
Adding features for gameplay (sweepbar, boost, etc)
Locomotion: Have you tested different wheel types for better traction? Is the gear ratio correct (is the robot fast enough, or does it stall on inclines)?
Power Management: Are your voltage regulators overheating? What are your options for isolating the microcontroller power from the motor power to prevent brownouts?
As we move toward final integration, you need to decide how your devices will communicate (e.g., remote control to robot, or sensor node to base station). You are required to research and compare two specific communication methods to determine which is best for your project context.
Research both protocols and document your findings. You should consider:
Hardware Requirements: Does it need a separate module (like a generic RF transmitter/receiver) or is it built into your microcontroller (like the ESP32)?
Complexity: How difficult is the code implementation? Do you need specific libraries (e.g., RadioHead vs esp_now.h)?
Reliability & Range: Which is less prone to interference in a classroom environment? Which offers better range or lower latency?
Data Structure: Can you send complex data structures (structs) easily, or are you limited to simple strings/bytes?
Key outcome: Justify your choice of communication protocol based on the specific constraints of your project (e.g., "I chose ESP-NOW because I need two-way feedback," or "I chose 433MHz because I am using a basic Arduino Uno").
Like the last sprint feedback is really important.
Create another, different, google form and send it out for feedback
When gathering stakeholder feedback, ensure you include questions specific to the functionality and ergonomics of your device.
Instead of generic questions, ask things like: "Is the controller comfortable to hold for long periods?" or "Do you feel the robot moves too fast for this track?" or "Is the LED display bright enough to read in daylight?"
Now test some other projects and add feedback to their forms!
Just like before, it's time to review our feedback, record our progress and reflect on how well, or poorly, we have gone so far.
Most of the features and functionality of your game should be complete by now. The last sprint is NOT the time to be still be adding critical features. If you haven't implimented it by now, be honest, it's never gonna happen. Pivot, scrap the feature so you can concentrate on refining and polishing what you have.
Fill out Sprint 2 Testing and Feedback now!
and
Fill out Sprint 2 Project Reflection now!