Category Archives: Sprint-3

Sprint 3 Retrospective Blog

With new experience gained from both Spring 1 and Sprint 2, Sprint 3 began without delay as I and my team worked to finish up all our loose ends before the coming end of the semester.

As a team, we all worked very well together in all stages of the final sprint. There was good communication through Discord and SMS to coordinate meeting times both in person and online, through which we collaborated to find solutions to the backlog issues. We were able to effectively work this way, evident through the team’s ability to complete eighteen out of the twenty-one weight we planned at the beginning of the Sprint. Some of the loose ends we needed to wrap were: 1) to get the frontend working, 2) to implement the buttons, 3) to update the Add Inventory Frontend documentation.

Because of the limited time we had, the team was not able to start implementing the new Add Inventory Frontend wireframe design which had been added in Sprint 2. However, we were able to get the frontend to run which we based off the code from Guest Info Frontend. This fix included adding a developer mode which allows for changes made in the code to be automatically updated to the frontend without needing to stop and restart. In addition, my team implemented the original button design and updated the documentation to reflect the new frontend features listed above.

My team and I decided that because there was not enough time to implement the Add Inventory Frontend wirefram design, it would be best to let the next Capstone class pick up where we left off. Firstly, the current layout is not the one represented by the wireframe. This would need to be updated. Secondly, the already created buttons would need to be linked to the backend using the appropriate endpoint call. Both of these are already issues in the backlog and can be used by the next team.

Seeing this sprint and the semester coming to an end, I feel accomplished with the work my team and I were able to get done. I personally learned a lot about the GitLab working environment, linters and how to use them through pipelines, designing frontend frameworks through Vue and HTML, and most importantly, meeting with a team to plan the backlog, collaborating to solve our issues, reviewing code solutions, and presenting our work to the professor at the end of each Sprint and to the entire class at the end of the semester.

Overall, this Capstone class was a growing experience through which I increased my ability to adapt to unfamiliar situations and became more comfortable with taking the initiative at certain times, especially when I was Scrum Master in the first Sprint. I am happy with the progress I and my team were able to make together this Sprint and throughout the entire semester.

Activity links:

Fix Frontend Build: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/49
Description: Redesigned how Add Inventory Frontend is build, implementing the developer build allowing for live change updates.

Update Frontend Wireframe: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/12
Description: Updated the frontend wireframe in Add Inventory Frontend which had not been merged in Sprint 2.

Update Documentation: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/46
Description: Updated the Documentation in Add Inventory Frontend to reflect the new features added in all three Sprints.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

CS-448: Sprint Retrospective

Sprint 3 Retrospective

What worked well

The issues the team had made for this sprint were larger in scale, but broken into smaller issues. This was done mainly to have enough issues for everyone to work on. However we found that working together during the scheduled class periods led to greater success rather than working on the issues individually. The team utilized mob programming in order to complete many of the issues for sprint 3. We preferred this approach because some of the issues were dependent on other issues being completed first. Therefore each member would have to wait until the previous issue was completed to work on their issue. Because most of the team members had little experience with the topics related to the issues we worked on, mob programming was also beneficial in allowing us to problem solve together.

What didn’t work well

One thing that did not work well was how the team managed our time during this sprint. By the end of the sprint, the team had completed most of the issues in weight, but failed to complete all issues. The team could have communicated better to ensure we had completed all the issues before the sprint review. Although the team benefitted from mob programming, mob programming did not have to be as heavily relied on if our issues were better written. In the effort of making the issues small and concise, we may have went to far when breaking down issues. Because this was the team’s third sprint working together, we have had enough time to get used to how each other work, the workflow, and GitLab itself. Therefore for this sprint, there was more that worked well than what did not work well.

Changes to make as an individual

A change that could be made as an individual is to encourage others to voice their opinions on what they think should be done. As stated above, the team completed issues through mob programming which led to multiple in person meetings and discussions. During some meetings, when we would get stuck and unsure what to do, I noticed I would list ideas of what I thought the team should do. Rather than always voicing my opinion, I would make the change of asking the other team members what they thought was the best plan to solve the current issue. This change would help everyone feel that they are included in the discussion and voicing their opinion is encouraged.

Changes to make as a team

As a team, a change that could be made is having better time management and keeping better track of important dates. As mentioned previously, the team failed to complete all issues from this sprint. This was partly due to the team thinking we had another in person meeting to continue working on our issues. This could have been avoided if we had been more on track with due dates. There were times where a team member did not communicate well resulting in missed meetings and confusion. A change the team could have made is to work with each other so that everyone stays on task and does what is necessary to forward the team’s progress.

GitLab Activity

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

Sprint 3 Retrospective

This sprint was heavily focused on the InventoryBackend repository. One of the main goals of this sprint was to have made some meaningful refactorization to the backend that would take care of out of date code. This old code would turn out to cause a lot of confusion later on when we would attempt to write automated tests for the backend.

Our team met with members from OL Team 2 to discuss what resources they had to help us implement nodemon. This was then taken over by another member of the team as I mainly worked on designing the tests for the backend. Afterwards I would work with another team member who was working on researching and setting up mocha and chai in the backend. Together, we would take the tests I designed and attempt to develop working tests for each of the API calls. The biggest issue we ran into was that the test we were using as an example from the GuestInfoBackend seemed to be unit testing the endpoints rather than testing the API calls. This paired with the errors involving Gitpot and trying to connect to a local host left the team unable to get working tests by the end of the sprint. However, the information we have learned can still be documented so that the next team/developer who looks at this issue wont have to start from square one.

What Worked Well:

This sprint felt like we had a better understanding of the issues on our board before going to the sprint. This led to us having a good plan for the order in which the issues needed to be addressed. This also means that unless one of us ran into an issue, a lot of these issues could be handled individually. While this was great for cutting down on the lengthy meetings we were having in the past, it did also hinder the communication between the team.

What Didn’t Work Well:


Throughout this sprint, we had significantly less time in meetings. Although it feels like the same amount of team and individual effort was put into this sprint, the overall takeaway from the sprint feels less. With most of the work being done individually, there were a lot of opportunities for information to not be shared with the team. This made it hard to keep up with issues and what was going on outside of the standups. 

Team Improvements:

Moving forward, if we were to have another sprint together I would say that our biggest improvement can come from better documentation. Our first 2 sprints we were lucky enough to have a lot of time actually working together as a team. Having less verbal communication this sprint meant we were very reliant on our stand-ups and any documentation we created for issues. Creating better comments in the issues keeps everyone on the same page for what has been done to fix the issue. Especially if we are stuck and ask for help from another member of the team. 

Personal Improvements:

When it comes to working on sprints in the future, I plan to keep myself involved in what the rest of the team is doing throughout the sprint. While it was great knowing I could trust my team members to handle the issues on their own, it still felt like I was missing information or not keeping up with the collective knowledge. 

Issues:

Meet with OL team 2 to discuss implementation of Nodemon:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/100 

Design unit tests for InventoryBackend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/96 

Weight accepts the wrong type of input in the frontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/56 

Create removeInventory automated Test using Mocha and Chai:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/55

From the blog CS@Worcester – CS Learning by kbourassa18 and used with permission of the author. All other rights reserved by the author.

CS448 Software Development Capstone – Sprint #3 Retrospective

The third sprint was uniquely challenging for our group, because each of our members were faced with personal challenges and setbacks while we worked to resolve our assigned issues. I was primarily concerned with writing a unit test for the ‘InventoryBackend’ microservice that would evaluate the operation for adding a weight value to the weight stored in the inventory. This test was supposed to ensure that responses were returned for either of the operation’s two outcomes – a ‘200’ HTTP status reflecting a successful addition to the Inventory’s weight, or a ‘401’ HTTP status, indicating that the HTTP request contained invalid values for one or both of the ‘weight’ and ‘Id’ fields.

While discussing the unit test design process with Professor Wurst, we realized that the HTTP ‘401’ error code was the incorrect choice for communicating the error to the user. According to the list of HTTP response codes hosted by Mozilla, the ‘401 Unauthorized’ error code from the server reflects an unauthorized or unauthenticated request from the client. In our situation, where there exist invalid values in our HTTP request, the error code ‘400 Bad Request’ would be more appropriate.

I was not able to get my unit test to a point where I felt that it was ready to be merged into the main ‘InventoryBackend’ branch. I was having difficulty getting the backend server to build in my Gitpod workspace with the ‘bin/up.sh’ command, which caused the portions of the test which checked for a valid HTTP response to fail. I also had doubts about the construction of my test, as one of my groupmates had pointed out that my test should be using the getInventory function to monitor the value of the Inventory’s weight as the operations are performed.

One of the things that was holding me back the most, in addition to the challenge of researching and learning unit test design, was that I got sick in the middle of the sprint. It wasn’t anything serious, but my energy levels and ability to concentrate were impacted, which ultimately had an effect on my work this sprint. I would have liked to contribute more than I was able to in this last sprint.

Another thing that was holding me back form designing the best unit tests that I could was that I need to spend more time studying and reading about HTTP backend operations. I’ve realized the importance of setting aside the time to read, absorb, and reflect on the material through writing and taking notes as part of the learning process. Over the summer after this semester, I want to take the time to read a book on software unit testing and take notes as I read. I’ve been considering taking the advice from the Apprenticeship Patterns textbook to build my own personal wiki as a way to organize my notes on all the subjects I’m interested in, like software development, information technology, and data science.

Despite the challenges in my own life during the sprint, my team was a tremendous support during the sprint and I’m really proud of all the things they were able to get done while I wasn’t feeling my best. We all did our best to communicate over text between meetings to coordinate our next moves, and we all still showed up for our scheduled voice calls to work on our assigned issues together. I would be happy to work with any or all of them again, and I’m hoping to keep in touch with all of them after graduation.

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

Sprint Retrospective April 30, 2024

During this sprint, I worked on three issues that were assigned to me. As a group, we all did well in our first and second sprints and felt we had much to improve on during both of those sprints as well as this one. There was mainly one area where we could improve as a team. The first issue that I worked on this issue was issue #99 “Investigate InventoryFrontend to ensure hot-reloading the backend doesn’t affect functionality”(3).

When looking into this repository’s script files I was initially very concerned with the possibility of nodemon being able to be implemented without causing functionality issues. Within the script files there was code that would need to be refactored, and code that connected the backend to the frontend was also outdated and would need to be refactored, they were both using an outdated way of classifying inventory weight. They were using individual item objects instead of a weight integer. I met with Dr. Wurst to discuss what would need to be done in order to progress, thankfully I was mistaken in thinking that both repositories would need to be refactored before nodemon could be implemented, I was told to look into the inventoryFrontEnd to see how I should implement nodemon. The next issue I started working on was “Research nodemon as a way to run backend in ‘development mode’ “(1).

I spent a very long time on this issue looking through nodemon documentation, articles discussing implementing nodemon on pre-existing repositories, blog posts discussing the best ways to implement nodemon into pre-existing projects and only after all of that, I decided to look at the inventoryFrontEnd which had already implemented it. After looking at where it was implemented I was very confused as the solution seemed to be deceptively simple. The implementation of nodemon falls under issue #98 “Edit script files to accommodate hot-reloading for InventoryBackend”(2).

Only one line of code was needed to properly implement it. I was both relieved and very upset by this. I had spent hours researching and reading what needed to be done being very confused by conflicting information from different articles and blog posts only for one line of code to be written. While I did not need to do as much research as I had done, I did learn a lot about nodemon and how it works. The last thing that I will discuss in this blog post is how our group worked together and what we could improve upon for future sprints.

Our group learned a lot from the previous two sprints and this sprint we were able to improve upon our performance significantly. However, we definitely could improve with checking the calendar for when the meetings with Dr. Wurst are. When the sprint review came up I had completely forgotten that it was that day, thankfully we were able to reschedule for the next class to have the review. We got very lucky this sprint, but in future sprints we would have to be far more careful with deadlines and important dates.

Issues:
(1) Issue 97 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/97
(2) Issue 98 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/98
(3) Issue 99 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/99

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Sprint 3: A Candid Look at Our Sprint Journey

Sprint Retrospective
Reflection on what worked well:
Hey Everyone! During this sprint, our team demonstrated effective communication and productive collaboration. We were able to complete our assigned issues on time, and each team member contributed by conducting individual research. The meeting with the professor provided valuable insights and guidance, particularly regarding the challenges we faced with Docker Compose and the startup process involving RabbitMQ.
One aspect that worked well in our favor was our ability to divide tasks and responsibilities based on individual strengths and interests. This allowed us to support each team member’s expertise and ensure that the workload was distributed evenly. Additionally, our regular check-ins and progress updates made the ideal coordination and helped identify potential obstacles early on.
Reflection on what didn’t work well:
Despite our best efforts, we encountered some difficulties with Docker Compose and the startup process involving RabbitMQ. Configuring the containers to communicate effectively and ensuring proper dependency management proved to be a great challenge. However, these obstacles presented valuable learning opportunities for our team, and we gained a better understanding of the areas that require further improvement.
Another area that could have been improved was our initial planning and estimation process. While we successfully completed our assigned tasks, there were instances where we underestimated the difficulty of certain issues, leading to potential time crunch or scope.
Reflection on what changes could be made to improve as a team:
To enhance our team’s performance, we could explore more effective ways to share and combine our research findings. By creating a collective repository or doing regular knowledge-sharing sessions, we can ensure that everyone is up-to-date with the latest ideas and techniques. This would not only help grow a collaborative learning environment but also prevent duplication of efforts and assist a mutual learning affair within the team.
Reflection on what changes could be made to improve as an individual:
As an individual, I could focus on improving my expertise in JavaScript linter tools and debugging utilities. By focusing time to hands-on practice and exploring more advanced features of the tools we’ve identified, I can better contribute to the project’s code quality and debugging efforts. This would not only enhance my technical skills but also position me as a valuable resource for the team, capable of providing guidance and support when needed.
Furthermore, I could enhance my documentation skills to ensure that my research findings and insights are effectively communicated to the rest of the team, clear the way for helpful information and collaboration. Clear and brief documentation can serve as a valuable reference for future sprints and aid in onboarding new team members.
We have provided a broad overview of our research on JavaScript linters tools and debugging utilities, which will be a valuable resource for future teams who tackle this. The dedication to exploring various options and understanding the strengths and weaknesses is what we want to leave our mark on.
Overall, I would say for Sprint 3 as a cleanup and research Sprint, it allowed our team to identify areas for improvement and gain a valuable experience into the challenges we faced. By implementing the suggested changes and continuing to collaborate effectively, we can enhance our productivity and deliver high-quality results in future sprints. Open communication, continuous learning, and the strive to move forward will be key to our success as a team.

andicuni
May 5, 2024
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/experiments/guest-info-backend-java-script-linter-testing-debugging-fork/-/issues/1 One of the issues I worked on was the JS Linters research.

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

sprint 3 retrospective

This sprint, the bulk of my time was spent looking into ESLint and keeping up with the team to ensure that we are meeting our goals. I also made a tentative branch for how the pipeline should look like after the linters are added, as these changes were never pushed by the team that was in charge of actually putting the linters in the ReportingAPI repository. I also participated in a clean-up of previous issues that were completed, and reviewed some merge requests from team members.

ESLint Research and Configuration: I checked to see if ESLint could theoretically fulfill the needs for an active linter that shows JavaScript syntax errors in the editor, and it seems like with proper configuration it does fit that role. I found that the ESLint version we currently use is out of date, and the old style of configuration file (.eslintrc) was hard to get working properly. With the new format for ESLint configuration, I found that ESLint needs to probably be installed locally in order to have this take effect properly, and that we should update the ESLint version we use in LibreFoodPantry to adopt the new configuration standard.

Pipeline Configuration: I configured the pipeline based on the GuestInfoBackend repository, and it currently fails because there are no linters actually installed in the repository. The idea is that when the linters are merged into the main branch, this pipeline branch should fetch those changes, push them to the branch on GitLab, then check to see if the pipeline does work correctly with that. Theoretically it should.

Cleanup ReportingIntegration: I checked over the work I did in this repository and it looked fine. I also adjusted Hieu’s branch where he cleaned up some of the documentation.

Cleanup ReportingBackend: I checked over the work I did in this repository and it looked fine.

We had some logistical issues again this sprint, but ended up completing nearly all of the work that we set out to do, thankfully. The problem was that there was a kind of rush during the last few days leading up to the sprint review, which led to me having to take charge as scrum master and keep up with each group member actively in the days leading up to the review to make sure everything was completed. That being said, our communication was the best that it has been this semester during this sprint, the one issue I was consistently having is that we should be sharing communication with each other, but team members were direct messaging me personally for issues they were having.

On my part, I do think I could’ve spent more time with the ESLint issue and also looked into other solutions, but I definitely was feeling crunch from other courses and ended up putting the work for this course on the backlog while other courses were piling work on me. I’m happy I got to a relatively satisfying conclusion with the issue, but I feel like I could’ve done more. On the part of being scrum master, I performed much better at keeping everyone on task by checking in every week, though I could’ve been a little more strict so there was less crunch at the end of the 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-3 Retrospective Blog Post

Tasks/Issues that I worked on in Sprint-3:

1. Cleanup and Enhancement (Reporting Backend) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/79):

Assigned alongside Isaac, Victor, and Andi, I undertook the task of consolidating enhancements made to the reporting backend during earlier sprints. My role involved conducting a thorough review to ensure clarity and accessibility for future developers. While I completed the task successfully, I acknowledged the need for additional time to refine code cleanliness further.

2. Documentation Review (Documentation Repository under Reporting System) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/documentation/-/issues/11):

Independently assigned, I reviewed the reportingsystem documentation repository to identify any inaccuracies. After a comprehensive review, I found the repository to be accurate and well-structured, requiring no immediate changes. However, I recognized the importance of ongoing documentation maintenance to keep information up-to-date.

3. ReportingIntegration Documentation Update (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/merge_requests/10/diffs?commit_id=c972ae9723af3eefcf3d2f09b4827c9c942b368c):

In another individual task, I updated the reportingintegration documentation to reflect recent changes. This included updating the lint.sh file to ensure proper linting functionality and modifying file paths for improved readability. Despite encountering an issue with dead links, which I consulted with our professor about, the documentation updates were otherwise successful.

4. Code Cleanup and Refactoring (Reporting Integration) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/commit/ece7535bbd6e9c5901083e541fb450dcbb9466b8):

Collaborating with Victor, I worked on cleaning up and refactoring code within the Reporting Integration module. This involved rewording, rephrasing, and highlighting phrases in documentation files to enhance readability. While completing this task without issues, I acknowledged the need to dedicate more time to code cleanliness for improved team collaboration and understanding.

Reflection on what worked well:

Improved Docker Pipeline Configuration: We successfully configured Docker pipelines, addressing path issues and ensuring smooth file copying into containers, enhancing our development workflow.
Effective Scripting: Our development efforts were streamlined with the implementation of scripts like bin build and push.sh, contributing to efficient Docker operations and backend development processes.
Communication and Task Management: Clear communication through GitLab issues and effective task management ensured that team members were aligned, contributing to productivity and progress tracking.

Reflection on what didn’t work well:

Linter Configuration Challenges: We faced difficulties in setting up linters, particularly with es.lint configuration files and syntax checking, impacting code quality validation.
Docker-compose Issues: Challenges arose in creating Docker Compose files that adequately handled starting MongoDB, RabbitMQ, and backend services, causing complexities in deployment.
Dependency Management: Struggles with dependency management led to inconsistencies in development environments across team members, hindering collaboration and code compatibility.

Reflection on changes to improve as a team:

Enhanced Teamwork and Collaboration: We aim to foster a stronger collaborative environment where team members assist each other with tasks and share knowledge effectively, improving productivity and problem-solving capabilities.
Improved Documentation and Knowledge Sharing: Documenting processes, configurations, and troubleshooting steps will facilitate smoother workflows, onboarding for new team members, and better understanding of project intricacies.
Streamlined Development Processes: Automating repetitive tasks like linting and formatting will reduce manual effort, enhance code quality, and ensure consistent development standards across the team.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Sprint-3 Retrospective

Going into Sprint 3, we completed a majority of the issues that we wanted to get out of the way except for backend testing. We had already put in a lot of time and effort trying to get the test-runner to work but it was still facing some issues. 

It was having some issues running on other computers and sometimes the test would fail because it would start too early for the backend server thus we had to implement a way to delay the test-runner container so that the backend server could finish processing.

Despite the goal of the sprint is to clean up any loose ends, it was still important for us to finish any issues started and close off any issues that we couldn’t get to. Stepping back from backend testing I decided that it was best for me to finish the “Set up GuestInfoIntegration” Epic this meant I had to:

After getting those finished it was time for me to get back to working on some testing. The test-runner was still having issues, and it was difficult for me to find a solution so that the test-runner script wouldn’t start too early while the backed server was loading, but eventually, the team thought it was best for both docker-compose files to be put together. Doing this, I can insert a health check on the test-runner container so that it can check if the backend or the Mongodb was completed before running. Before we had inserted a “sleep” right between the docker-compose running the backend server and the docker-compose running the test-runner container. This was in the test. sh. I decided to work on some tests as well, In the test-runner remote branch that we merged in the main, I made sure that the test will return the right status code and error messages. It’s worth noting that the test was implemented when working on the issue “Add HTTP request testing using npm test script”. But have been revised in the test-runner branch to better fit our designs list on the issues below:

The listed issues also have been designed so that when the next group picks up the project then they will be able to see what we as a team were planning when looking at our test.

The test-runner merge is also modified to work with the pipeline and the test stage will react if something is wrong with the test. 

When it comes to clean-up we went ahead and finished up all the issues that were working and closed off any other issues that weren’t going to get into. Any branches that were left over have been deleted and merged and all the finished epics are closed off while the unfinished ones have been moved to open.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Retrospective Blog #3

The third sprint was the shortest, but I feel like it led to some of our best work. I only worked on one issue this sprint, as we had less weight than the others. The issue was to create the test.sh file, which was being continued from the last sprint. The issue got completed with the help of Scott and Moses to clean up the queue, and the link can be found below. This blog will go over my retrospective thoughts now that the final sprint is complete.

There were many things that went well throughout the final sprint. One thing that went well was our communication. Our team has had this positive throughout all of the sprints, and it continued here. We talked to each other all the time whether on Discord or by call. Another positive for our group was how we never deterred from the goal, and from the very beginning, we were determined to finish this sprint strong. This sprint more than the others, I feel like we knew what to do and immediately got to work. The experience surely helped with that.

There were also some other aspects of the sprint that I think we can still get better at in the future. One thing that I think we can still improve on is our weights as a lot of these issues we worked on were carry-ons from the last sprint. We can still improve on that, but I think we got better throughout the semester. Another aspect that I think we can still improve on is our experience. We did not have experience with short sprints like this one, and so I feel like that put a lot of stress on us that would go away with more short sprints. The more experience we get with shorter sprints will only make us better.

There were also some things that I feel that I personally can improve on. One thing was that I was sick for most of the sprint, so I was not able to put in the work that I wanted at times. I know that being sick is uncontrollable, but I wish I would have helped more than I did. That is the great part about a group though, as everyone helped me through that time. Another thing that I could improve on is my knowledge of software development. I do not think that I had zero knowledge, but I feel like I can always get better. The more I can learn, and the more experience I get, the better I will get at this in the future.

With this third sprint over, all the sprints have finished. I really enjoyed working through all three sprints, and I am thankful for the experience this has given me. In the beginning, I was really worried about how this would all go, and I can safely say that I do not regret a single day throughout all three sprints. I love the group that I was assigned to, and I think we did a great job teaching each other aspects of the work we did not know. I feel like we all made each other better, and that is all you can ask for.

Issue Links

  1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/48

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