Sprint Retrospective 5

During this sprint we organized our project boards more and actually made some progress to enhancing our form. I personally worked on an issue that added some styling, a little bit of reordering, and added a new field to the form. There was some functionality that needed to be added for this field to work properly so I had to do a little bit of review to remember how to perform certain functions in Angular. This sprint was again, more productive than the previous and I’m content with what was accomplished during this time. I think there could have been more work completed but this was a problem with communication between groups more than an individual issue between group members.

The first week of this sprint was honestly, a complete disaster. We were happy as a group at the end of our sprint planning and some group members were already starting to work on what they thought were “their” tasks. The problem was, we never assigned the tasks to individuals on Github and then the other group thought they were working on the same material and claimed it, also without directly assigning someone to the work. Miscommunications like these seem to be a recurring problem with this project and I honestly think it is partially due to the inability of the two groups to meet face-to-face to directly resolve this issue. I think this is an issue that would be immediately resolved if all groups working on this project next year were in the same section of the capstone. This would allow for direct, brief, meetings between the two groups to discuss any possible issues in overlap of work, claiming of work, and even just generally sharing what each other group is thinking of for a vision of an up-and-coming feature or functionality. While we’ve done our best to document our thought process to the extent of sharing the flow of the entire intake form, it still seems like both groups are not entirely on the same page.

There are fields that the other group seems to have talked to the customer about and that they apparently want, but when we spoke with the customer, they explicitly told us not to worry about the fields in question. These issues can be found on our Github as optional fields, and the address field.

From a stance of what was accomplished and what went well, we’ve added some new functionality and seemed to have discovered a way for the form to flow and generate fields as needed to maximize efficiency. While most of this functionality is not yet implemented, I made the first step in adding this functionality by adding the “household size” field. This involved adding a new field to the constructor for the customer object, adding some ng-if functionality in the HTML and even adding a little bit of styling to the submitted output. While not all of this was explicitly mentioned in the issue as needed for completion of the task, I felt that adding the styling was something that we were going to need to do eventually and just added it. This was documented in both my commit message and in the pull request made for merging this completed issue.
Github issue (household size): https://github.com/cs-worcester-cs-448-sp-2019/Theas-Pantry/commit/927b98896f32fed1325e57712467a420ab6c93ec