Sprint Report 3 - nford18/spherical-easel-w24 GitHub Wiki

Prepared by: Nick Ford, Caleb Roe, Travis Johnson

Intended Progress

For Sprint 3, we had two goals: finish up UI components, and add some more backend features for starring and unstarring constructions. We also wanted to focus on cleaning up the database further for future feature testing.

Nick planned to work through adding the starredConstructions array to user profiles and update any references to UserProfiles to let the user keep track of constructions that they like.

Caleb planned on finishing the Ui enhancements with the construction option buttons, as well as researching the issues encountered with creating a vercel playground instance. Finally, he was going to continue working on the starred construction list creation feature as time allowed.

Travis planned to work on the function that would handle staring and unstaring constructions that would implement the function that Nick created. Along with this he planned on deleting all of the public constructions from the Firebase database.

Progress Reflection

Overall, each individual was able to complete either all or most of their slated tickets for this shorter sprint. We had several good meetings with our clients during this sprint where we were able to get clear guidance on starting the next batch of features.

Nick did not get everything done that he had planned, but it was a very busy week. He had multiple exams and projects to finish this week. He updated the interface and started amending the references to the interface. With this also being a 1-week sprint, Nick feels okay about his progress.

Caleb was able to complete all the critical tickets, but he was unable to complete all of his planned work. He came down with the flu during the later half of the sprint and was out sick for most of the following week, which impeded his ability to do extra work over spring break. the shorter sprint was a challenge to coordinate due to tickets being fairly complex for a one week turnaround.

Travis got most of what he planned done. He still needs to test the function that he created but other than that he completed the other task for deleting all the public constructions. With the short sprint and midterms during this period Travis believes he put forth a solid effort. even so, Caleb is happy with his progress on this sprint.

Problems Encountered

We didn't encounter many problems during sprint 3. All of the tickets had well defined work or previous research attached from sprint 2. The closest problem was one of time constraints; some of the planned tickets were simply too complex to reasonably finish in one week.

Nick did not encounter any programming problems. The only problem was the lack of time due to other classes and the short sprint.

Caleb similarly only encountered issues with the time constraints and being sick.

Travis encountered similar problems as Nick with time constraints.

Project Progress

We were able to hit all major milestones for where we wanted to be at this point in the project. Overall, the requirements have moved a bit since the first sprint and with a lack of testing availability, we are at the development stage where a lot of the future work will entail more back-end functions. There is more uncertainty across the team whether our newly built code will perform as expected within the already established code base, especially when we have already encountered bugs or unexplained code behavior that has required additional work to understand.

Nick has added the array field for the tracking users' starred constructions and started fixing the related references. Nick is a little worried about the team's overall progress toward its end-goals for the project.

Caleb primarily worked on finished up the UI buttons critical for future feature implementation and testing. He is still confident that the team will be able to get the planned features finished by the end of the semester, but He shares similar worries as his teammates whether there will be unforeseen roadblocks in implementing the required functions for the back-end.

Travis has created multiple functions that will delete and change data in Firebase. Travis believes that the project has gone well so far, but the lack of testing he has been able to do has provided a little uncertainty with the functionality.

Update of Burndown Chart

With the shorter sprint week and being late in setting up the sprint (we had to confirm what work could be completed in the shorter sprint), we had some issues with achieving a solid burn down chart. We are generally happy though with the progress shown.

sprint3-burndown

Teamwork Reflections

Nick thinks team communication has gotten better over the past two sprints. The team has restructured the client meeting schedule to make sure any big questions the team has, get answered. This has improved what the team can get out of the meetings.

Caleb is happy with the improved communication seen with the clients and team during this sprint. The clients are readily available each week and the team has always been able to get a lot of important clarity from them both on the existing code and their goals. The team restructured how we handle our client meetings a bit, and that has helped tremendously with the flow of meetings.

Travis believes that the team has much more meaningful meetings with the clients and also as a group itself. The team has made okay progress on the project, but great progress on the team communication side.

Conclusion

Reflecting on Sprint 3, we have seen growth with the communication for both clients and teammates. The progress has still been shaky at times due to missed client information or roadblocks with the existing code-base. Given that, we as a team are still confident in our progress, and are still on track with planned development features for the two remaining sprints. We will need to remain cautious during the next spring as we tackle more of the back-end features that need more interaction with client code. Our lack of ability to test means we cannot afford to spend time on features that we cannot adequately prove are working as intended at the end of the semester.
⚠️ **GitHub.com Fallback** ⚠️