Category Archives: Sprint-1

Sprint 1 Retrospective

Overall I think sprint 1 went well. I think we all did a good job of keeping each other updated and asking each other questions if we became stuck. We had times when life got in the way and work didn’t get done and we made sure to let each other know. We were also open enough to communicate with each other when we realized that issues may not have been merged for a long period after being reviewed. All of us displayed aspects of the original description of the culture we wanted in the working agreement: open-mindedness, honesty, respect, and accountability. We decided how much weight everyone should try to complete to divide the work evenly and fairly before the sprint started and we kept to it for the most part.

I worked on 4 issues in total. I worked on one with the group and 3 on my own. The issue I worked on with the group was “Gitpod Dev Environments -InventorySystem/Documentation”. In this issue, we set up the files needed to configure the Gitpod Dev Environment for Inventory System Documentation and asked any questions we had to make sure the rest of the similar issues would go smoothly. The issues that I completed on my own throughout the sprint were “Move from `commands` to `bin` – InventoryAPI”,” Add AlexJS linter to pipelines – InventoryAPI”, and “Add AlexJS linter to pipelines – InventoryBackend”. The “Move from `commands` to `bin` – InventoryAPI” issue was a bit difficult because there was no build or test file. I figured out that I had to disable those two jobs for the pipeline to run. For both of the issues the lint.sh files weren’t created during the “move from commands to build” issues for the respective projects so I copied the file from a project that already had one. Because I knew that all of the linters that were included in the file also applied to each of the projects I worked on, I left those linter commands along with the command for AlexJS. However, I only enabled AlexJS in the pipelines for since the issue was only created to add AlexJS and we planned on adding the rest of the linters to the pipelines of the projects during sprint 2.

As a team, I think we did fairly well but we needed to adjust how we work to ensure there is evidence of everyone’s contribution on GitLab. Most of the communication was through discord which resulted in a good amount of the team receiving a poor individual grade for sprint planning. We realized this and decided to split up adding issues and weight for the sprint planning and backlog refinement for future sprints. We also did not rotate reviewing issues as we originally planned when creating our working agreement. In future sprints, we plan to set up a system that will ensure that there aren’t certain people who are reviewing the majority of issues. We aren’t sure if we would like to set time aside during our weekly meeting on Discord or set a system where one would just review the last issue in the “needs review” column. As an individual, I need to make sure I’m on top of my work throughout the sprint. Although life can get a bit hectic, I need to make sure I am pulling my weight for the team. I want to plan specific days where I work on issues to stay on track.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

sprint 1 retrospective

This sprint, I handled the Gitpod Dev Environment implementation for the Reporting System, specifically for the Reporting Integration, Reporting Backend and Reporting API repositories. I also acted as the scrum master for the team, handling most of the logistics and communication with the product manager.

Gitpod Dev Environments: Import extensions via the .gitpod.yml file, set workspace settings via the .vscode settings.json file.

In terms of what went well, we did complete most of the issue weight (75% of the weight assigned for the sprint was dealt with). Speaking with my team members, we agreed that the meetings were productive and efficient, and we didn’t waste time on any of the meetings we had. I made it a point to not have meetings that could have been done over a short text conversation, and it seems to have paid off. We also agreed that the communication that did occur was quality communication.

While we completed most of the work for this sprint, there was still 25% of the weight left. This was entirely comprised of the Reporting System Deployment issues where we had to write docker-compose files to set up MongoDB local volumes. In talking with the team, we thought that the weight didn’t reflect the difficulty of the task. In retrospect, looking at the Deployment epic again I can see that there was a lot of confusion, not only because of having to read through documentation for Docker, but also because the initial task that was to be done before the implementation through docker-compose files (the actual mounting of local volumes from MongoDB) was not accomplished by another team, and was even removed from their sprint. This was excacerbated by the approach we took, where each one of us worked on issues individually without much assistance from other group members. This changed towards the end when two team members worked on the deployment together, but by then it was still ineffective, especially considering the uneven distribution of issues. It seemed like the weight of issues did make sense in a vacuum, but considering that I did all of the Gitpod Dev Environment issues for example, it was obviously very quick to complete 4 weight when the first 2 weight was done, because it’s an application of what I just did.

Another consideration: I think having one person (me as the scrum master) deal with a lot of the issue-creating and handling GitLab logistics was efficient, it didn’t lend itself to the most clear working environment for my team members that weren’t very well acquianted with the workflow. Details were located in epics rather than easily accessed directly in the issue that was assigned, and it made it more difficult to see what you were actually working on. In addition, it made it seem as though I did all of the work in the activity log when in reality it was a cooperative process, and the byproduct is that I end up with all of the credit as well.

For next sprint, we should better assist each other as necessary on issues when complications arise. We should assign weights more accurately based on our experience on the last sprint, and allow all team members to share responsibilities on GitLab, both for learning and to better tell what’s going on. As an individual, I should be more proactive as scrum master to really address problems as soon as they arise, rather than leaving everyone to their own devices as long as they check in. With these adjustments, I think our team will be able to perform much better in the next sprint.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

Sprint 1 – Retrospective

Greetings everyone, I hope you all had a fantastic spring break. As we begin a new week, I wanted to take a moment to reflect on the recently concluded sprint 1. Undoubtedly, it was a unique experience for all of us as we delved into the real-world work environment. For many of us, including myself, it was a significant learning curve as we navigated the intricacies of our new job. However, I firmly believe that the challenges we faced during sprint 1 provided us with an excellent opportunity to develop our skills and learn from our mistakes.

Personally, I found myself drawing on the knowledge I gained from my computer architecture class in the fall of 2021. Although there was a long gap between that class and my current class, I was able to recap the essential concepts I learned in the CS-343 class, which proved to be incredibly helpful in my work. As we move forward with the next sprint, I am confident that we will continue to learn and grow, both as individuals and as a team. Let’s take the lessons we learned in sprint 1 and use them to make even greater strides in sprint 2.

As a team, we faced challenges during the first sprint, needing more time to learn how things work. However, we did our best to adapt and make progress. Moving forward, we will continue to improve our work process and complete tasks efficiently. During the first sprint, I faced an initial hurdle with getting visual studio code and docker to work on my new laptop. Fortunately, my Scrum Master and Professor were extremely helpful in guiding me through the process, and I was able to overcome the issue with their assistance.

After resolving the initial challenge, I was able to focus on other aspects of the work, and I quickly identified a pattern that required my attention. I noticed that the variables in the code were being declared with ‘var,’ even though they did not change throughout the program. Thanks to the previous team’s efforts, I was able to change these variables to ‘let’ or ‘const’, in a little amount of time. The second issue that I encountered during the sprint involved removing MongoID from guestinfoAPI. To accomplish this, I had to delete the MongoID schema from the schema folder and remove the schema from the Index.yaml file. With these changes implemented, the guestinfoAPI was updated and functioning as intended. To resolve the third issue, I updated the code in the Dockerfile to replace the existing Swagger CLI image with a multi-architecture version. This was done to ensure that there were no issues running the code on my M1 laptop and to ensure compatibility with other devices. By using a multi-architecture version, the code could run smoothly on different architectures and avoid any potential conflicts or errors.

To improve team performance in the next sprint, dividing the workload efficiently is crucial. This will ensure that tasks are assigned according to each team member’s skills and expertise, leading to a streamlined development process and successful outcomes.

Links to GitLab issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/62 “Change ‘var’ variable declarations to ‘let’ [or to ‘const’ when they don’t ever change]”
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/92 “Remove MongoID schema for GuestInfoAPI”
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/93 “Replace swagger-cli image with multi-architecture version”

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.

Sprint 1 – Retrospective

This week, the first sprint has concluded! And boy, there was a lot to learn and improve upon. For one, within my group, I was the Scrum Master, and it is a bit harder than I anticipated. I had some ideas to organize coming into it already, but sometimes, ideas don’t always meet with reality. At times, things were really effortless, and at others, they were rather difficult.

Some things that worked really well, was the overall organization. As a group, I realized that we were all heading into unknown waters, working with a code base that, though we had some idea of, in reality, we truly had no idea how much of it worked. Because of this uncertainty in many areas, I knew it was crucial to try and share our knowledge with each other as the sprint progressed. Some of the biggest boons, and though it was a bit of luck as well, was splitting our different members into the different portions of our issues.
As an example, we had a cluster of issues in our frontend, backend, and API that dealt with the same thing. Essentially, we had to update/add lots documentation, licenses, etc! This looked very simple at first, but there was some difficulty with clarity, since we simply weren’t familiar with what the specs were. We split three of our members into the three issues, and as we worked on the issues, I made a effort to make sure everyone is keeping each other updated, and this allowed us to realize that despite it being the same issue, we were actually doing things differently from one another. This allowed us to quickly establish what we should do as a group, and from there, we were able to progress forward without additional confusion.

Although things did work well because of our constant sharing of what we learned, not everything went smoothly. Some things that I tried to do as Scrum Master was make sure my group was not overly pressured or crunched for time. In my initial thoughts, I figured that we would have enough ‘brawn’ to sort out the issues with some commitment, and knowing how stressful a time crunch can be, I was very, very lax at times when important issues were being resolved. This relaxed attitude helped with the team morale, but it also did not do much to help with the issues and even stalled some issues. Moving forward, I hope to strike a balance between calming the team when things are not coming to a close, and trying to nudge them forward more when the deadlines are approaching.

As a team, I genuinely believe that we did very well. The biggest flaw in our teamwork, was not actually when we collaborated, but some team members doing things on their own, but these were only very minor issues such as changing issue names without telling anyone, which caused some confusion, as well as encountering a problem and trying to fix it without telling any other group members. Both instances, were very minor at best, and as soon as they were noticed, were stamped out already. Specifically, we know that moving forward, all group members need to try to communicate problems with the team before silently fixing them, and if a issue needs a new name, the new name needs to properly describe what the issue is.

Individually as well, I believe that I was very caught up with making sure that the team functioned, and though that was a great thing, it also negatively impacted my performance as an individual. I oversaw much of the progress, and was kept updated on how various systems worked, so I believe I have a good understanding of how the project works, but I have very little real work to show for it. Moving forward, despite being the Scrum Master, I have to not only manage the group and keep an eye on things, but also use my own abilities to push things forward.

Updating Dev container files
Updating/adding Documentation, licensing, etc

Finally, as much as there was lacking, I believe that moving forward, things will be much smoother. Our group has many great developers, and this was our first time doing a sprint. I already have many ideas on how to improve, and though it might be a bit of trial and error at times, we as a team, have all the ability to clear out our issues!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Sprint-1

Hi, and welcome to the Sprint Retrospective Blog. I have completed these tasks on GitLab for the group project; the team and I have been assigned to decide whether to implement these changes when necessary. For myself, I have done there is one activity that does require modifications, while the other three do not. These ISSUES weight totals are reasonable and easy to do once getting to the mindset of the work and practice.

The Issues:

Remove MongoID leftovers — generatewcfbreportfrontend (non-changes); This activity investigates whether there are any unused MongoIDs at the front end. It would appear that there are none.
Remove MongoID leftover – API (non-changes); the same goes for this with API.
Change the variables of JavaScript code on Front End (non-changes); After looking at the different variables, it appears to be simple to read and comprehend. Thus, there is no requirement for any necessary changes to be made here.
Remove MongoID leftover – Backend (changes). There are still MongoIDs available, and I will investigate this further. After I asked for feedback or assisted in making certain adjustments, the result seemed to be an improvement, and the team concurred.

My challenge concerning these works is that I took the time to review the codes, and everything seems to be great, so it does not require any modification. Even if it means setting aside some time so that you can go to the next activity or task in the sequence. On the other side, it makes it appear that all I have done is read the codes and determine that there is no need to update them, making me feel bad because I haven’t worked as hard as I should have been working on this project. To improve myself as an individual to have goals that include conquering negative emotions, recognizing that the quality of the job has been maintained, and making additional recommendations to the team regarding acceptable actions. In the upcoming year, is to improve my time management abilities and all of these measurements so that I can finish all of my work within the assigned time window. I need to improve my technical skills and knowledge to contribute to the team significantly.

The team and I had a rough start in completing all the tasks on the sprint backlog; we encountered some challenges along the way. We faced several technological challenges during the development process, leading to delays. Additionally, some communication breakdowns led to misunderstandings and duplication of efforts. To improve on those issues by strengthening our technical skills and knowledge. This work can be achieved through regular training and knowledge-sharing sessions. We also need to establish better communication channels to ensure that everyone is on the same page and that there are no misunderstandings. Additionally, we need better tracking and monitoring mechanisms to ensure we are on track with our goals.

In conclusion, our team had a rough start, but we got through a lot of success during the first sprint. We overcame some of the obstacles while working through the sprint backlog and completing some of the assignments.