←

Zack's CS Blog

CS-448: Sprint 2 Retrospective

ztram1

Sprint 2

What worked well this sprint

Sprint 1 was a good opportunity for the team to become familiar with each other, how we like to work individually, and the general workflow that we were to follow. After Sprint 1, Sprint 2 was much easier in terms of knowing what the team wanted to accomplish and how to accomplish it. During this sprint, we continued our weekly meetings because it was a good way for everyone to go over what was done the past week, and what needed to be done for the current week. Last sprint, we ended up leaving all of our merge requests open until the end of Sprint 1 which resulted in many conflicts which created extra work to resolve those conflicts. This sprint we decided to review and merge as issues are completed rather than leaving them until the end of the sprint. Reviewing as issues are completed helped the team to avoid merge conflicts.

What did not work well

Throughout the sprint, the team had issues that were dependent on the completion of other issues. An example of these issues were when the team were adding to the AddInventoryFrontend. The goal of the issue was to implement the functionality of actually adding inventory to the database which required multiple components to be added such as text fields, buttons, etc. Because the team as a whole had limited experience with frontend work, we spent time together researching implementation. When spending time together for research, we realized that implementation would be easier with the approach of mob programming. Utilizing mob programming rather than each of us being assigned an issue and completing individually helped save time. This is because if we were all assigned an individual issue then we would have to wait until the first person finishes their issue, then the next person could start their issue, and so on. Each of us would also have to pull the changes the previous person made. This process seemed inefficient, so the team decided to group the issues together and do them at once in one meeting where everyone was present.


Last sprint we also came across problems where there was miscommunication about when we would be meeting, which we aimed to resolve this sprint. However we still faced attendance issues regarding the team’s weekly meetings.

Changes to make as a team

One change that we tried to resolve last sprint was the issue of some team members not attending the weekly meetings. Unfortunately this issue was not fully rectified. In hopes to settle this issue for the next sprint, the team should have a discussion to clearly restate expectations which were initially defined at the beginning of the semester.

Changes to make as an individual

A change that could be made as an individual is having a better grasp of what needs to be done. Mainly due to having spring break in the middle of the sprint, there were a couple instances where I would forget a standup message to inform my team on the progress I have made individually. Although this sprint was longer than the previous, it actually felt shorter to me because of spring break and canceled classes which contributed to me having to rush at the end of the sprint to get my work completed in time. I plan to manage my time better, so this does not happen for Sprint 3.

Activity on GitLab

, ,

Leave a comment

Design a site like this with WordPress.com
Get started