Category Archives: Sprint-3

Sprint #3 Retrospective

The card I created for adding rabbitmq to docker compose

The card I created for adding message sending to the backend

This sprint not much worked well for me, mostly because of outside forces unrelated to the class. I simply was not able to put as much time and effort in as I wanted to. Most of the sprint was spent working on figuring out the messaging system. I was able to send and receive messages locally. What I was not able to do was send messages to other computers. I am pretty sure if I kept working on it I would have gotten it eventually; I found many solutions online that I did not get to try yet. 

That does not mean everything went poorly though. Something that did work well was transitioning between the two teams. This sprint I worked more with the event system so I had to meet with Derin and Rainiery more often. It was really easy to get the team together because discord is made to do that. If we were using zoom for class meetings it would have been a lot more difficult. 

I think my team did well this sprint. Marcos and Tim were able to do a lot of work on the front end and while it did not get where we wanted it to be we still got far. This sprint I think David was able to do a lot really fast and because of that he was able to start working on the integration portions. Cam was a lot like me in that he did a lot of work outside of our system with the IAM team. 

Even though this was our last sprint, there are a lot of things I can do to improve. The improvements may not be for the next sprint (there isn’t one), but they will be things for me to carry into my career. Time management is a huge thing I need to work on. Expecting to be able to do a ton of things all in one day just does not make sense. This sprint and this class really taught me that I can only be productive for a few hours at a time. Anything after that is probably wasted. It’s better to let a bunch of short work sessions add up. I also need to make sure I do a little bit every day. It is more efficient and I forget less if I minimize time in between work sessions. 

As a team, if we were to work together again I would want us to communicate more. I think David and Tim both were looking for more work to do during the sprint. I should have asked them for help with rabbitmq. We could have sent mock messages to each other and probably would have figured out the messaging system a lot faster. When I got stuck I also could have taken a step back and helped out with some other parts of the system, maybe doing something like helping test out the front end. That would have helped me clear my mind but it also would have helped make sure the front end worked for when we demoed it.  

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective


This was about filtering the data for the report.

We were able to get sample data from the other teams as a JSON object and used fake data to download report as csv.

Created a docker container registry and implemented it on gitlab.

Edited backend code so it takes a date and retrieves data based on that date.

Created the backend endpoints to receive the start and end dates from frontend.

The thing that worked well was that we got the system to actually run and get messages from rabbit mq which gets saved in the database to be used to pull the report. We were also able to connect it to the frontend and get a wsu style theme for the website. I think there was a lot that worked well considering this was our last sprint and we could not rely on another sprint add more work.

Some things that did not work well in this sprint was that we did not have as good of time management because there was so many projects for each class so we had to find chunks of the day to work when we can. However, I think our group gets a lot done under pressure and is able to complete a lot more in a few hours nearing the deadline as opposed to those same hours with free time. If we had more time to space things and did not have to worry about many other cs classes, then it would be much easier to focus on making the website as efficient as possible.

A few changes that we could make for future sprints as a team was to keep our eyes on the main goals of the sprint and not on small details. I feel like we were stressing on small aspects of the project when the big important features would have been just better to work on. We were struggling taking so much time to work with docker and get some of its aspects to work, and this took a way from upgrading and making the backend and frontend more efficient. I think next time we would spent as much time from the beginning to get the website up and running and having all the functions work properly for a user, then focus on the small details that won’ t take as much time to figure out in comparison to the bigger parts.

A few changes I could make as an individual is to find a balance with working on my team and working on my own. I feel that I was either working with the team too much or my own most of the time. I think in future it would be a lot more clear what our goals were and what to work on as the sprint went, but for this a lot of the task were things we could work on together and help each other out. I think even with all the factors we were still able to produce efficient work.

Overall, I think this sprint went very well and we got a lot accomplished. In the last week of the sprint we were panicking because of how much other projects we had to from 4 other cs classes and 5 including this class. However, we put our focus 100% on accomplishing everything and looking back we got more than enough done. It was very helpful to work in a team where we would help each other out and make brainstorming and planning a lot more easier. I think this sprint and this class in general will help us out in our future endeavors especially in the work field. A lot of the planning is what helped us out and our website was able to run which was very helpful for us to know that we did it. I’ll appreciate everything that I learned these past 4 years and from every professor and good luck to everyone on their future goals.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

 Links to evidence of activity on GitLab.

This is my frontend user interface for the report team

I updated my frontend from sprint 2 in my local service which I used the sample frontend example from the professor. I have changed the background and move the start date and end date in the middle same as the common website let the user input the login information.

Austin and I connected the backend API to my frontend API, which can let customers download the report for the inventory. It got succeed download the report for the inventory when we connect the API together.

My frontend design idea is based on the Worcester State University style of design. For the background picture and the color use, I followed the handbook of WSU style of design.

I implemented FrontEnd for reporting with the most recent version.

We Made some OpenAPI.yaml files for our FrontEnd and BackEnd.

We looked over TheasPantryReport.

We looked at the new architecture and plan accordingly.

Reflection on what worked well?

In Sprint 3, in terms of what worked well, the second phase was more efficient when team members worked together than ever before in completing the project plan. After a semester of teamwork, we have a deeper understanding of our ultimate goal and become more accustomed to each other’s habits. There will be a relaxed working atmosphere, and the team chemistry will encourage each other to push the project forward. The project progressed more smoothly, and the ZOOM meetings of the team were relatively frequent.

Reflection on what didn’t work well?

As for why it didn’t work out, there is a longer-term vision of the end product and the project’s future goals. Unfortunately, we failed to get the data of other groups. We made test data to run our report program. In addition, the team members were busy with other courses at the end of the semester, so there were some deficiencies in the adjustment of time in the later period. We had some confusion in the front end and back end docking. Through learning external materials and teamwork, we successfully solved the docking problem. Fortunately, we made timely adjustments and promoted the project objectives, and completed the group project.

Reflection on what changes could be made to improve as a team?

As a team with cooperation, smooth communication, and tacit understanding among team members are the basis and key to improving our team’s cooperation level. We would discuss the project after class and give some constructive suggestions about each other’s tasks. Good communication makes our team have chemistry. Through communication and cooperation, we have a thorough understanding of the team members’ tasks. Each knew the other’s project progress would be conducive to the overall advancement of the project. When a team member encounters a bottleneck in a task, we will appropriately slow down the overall progress and communicate with him to buffer his time to complete and push forward the overall task progress.

Reflection on what changes could be made to improve as an individual?

As an individual, I have watched and learned a lot about front-end production after class. It improves my front-end understanding and production skills, which helps my team better connect the front-end to the back-end. In this project, I learned and improved some problems encountered in team cooperation and realized the power of the team in finding and solving problems. In a team, the mutual understanding and tacit understanding among team members is the basic condition for the smooth operation of a team. It was a great honor for me to meet every team member in my last year of university, and I learned a lot of valuable experience from them in ZOOM meetings. At the same time, I am also very grateful to the professor for giving us an opportunity for a big team project, which benefited me greatly. I believe that I will bring my learning experience to my team in future team cooperation projects. Finally, I’d like to thank Worcester State University. It’s my great honor to be a member of the computer major.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Here is the Link to the repositories that contains everything we worked on Sprint-3. Backend, Frontend, Event system, and Keycloak.

Connect RabbitMQ receive file to DB: Connected the MongoDB database on the received file.

Implement Event System components: Implemented RabbitMq components for Event System.

Meet with other Event System Teams.: Met with other teams to finalize everything about messages.

New TheasPantryReport: The new Theas Pantry Report

Create two channels for both teams: Created two channels for both teams on the send and receive files.


For this Sprint, I worked mainly with Austin on the backend components such as implanting the rabbbitMQ, making API, and trying to get out system working.

What worked well / did not work well

For this sprint, what worked best was that we got our reporting system functioning. We have a system where the Rabbitmq receives the message from the queue and saves it in a database. From there the backend takes the data and converts it into a CSV so when the Frontend requests for a report the backend can send that CSV file to the user. One of the key things that I noticed that our group works well under pressure. We are always calm and composed. I don’t think there is something that did not work well, however, we should have managed our time wisely since the end of the semester was filled with many assignments.

What changes could be made to improve as a team?

As a team, this was our final sprint for the semester. In the future, if we work on this, I think it Is important to use the time wisely as we were up on zoom every night to make little progress towards the project. Also, whenever we had a question, we should have posted more on the issue board or could have asked the professor for more help but as a team, I’m so proud and happy with the way everything turned out towards the end.

 What changes could be made to improve as an Individual?

As an Individual, I should be communicating with my team more rather than just doing the issues that are assigned to me. I should try to manage my time wisely too. The end of the semester was a struggle since there were exams and projects from every class. I believe that we could have made our system more efficient and functional, but it turns out to be what I imagined from the starting. Working together as a team doing one task at a time was efficient for me and as a group.

Overall, this was a great learning experience. I will never forget this class or the reporting team. It was a pleasure working with amazing teammates who pushed me to move forward whenever I was struggling on an issue. I hope that the experience I got from the capstone will be a highlight for my future career in the field of technology. I wish all of you the best of luck and congrats on your graduation. Hopefully one day we can look back and enjoy these moments.  

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Like the second sprint, our team focused on developing the frontends, backend, and keycloak of the inventory system for the third sprint. I mostly continued work on the backend API and the Event System components. For the Event System, I specified what data has to be sent to the Reporting System. When adding inventory, the weight and the ID, which are integer and string values respectively, have to be sent. When removing inventory, the weight and the donor’s name, which are also integer and string values respectively, have to be sent. I also added a subsystem folder to the backend and inserted a basic JavaScript file called “send.js”. I’m pretty sure that Matt even added the code for one of the backend functions into the subsystem directory. I needed to edit “send.js” so that it could send the correct information but I ran out of time. For the API, I feel that I did all that I could considering I wasn’t able to test it with docker, either locally or with the docker-compose.yaml file. I was able to add Weight, ID, and Donor to the schema and finish the API code for the getInventory, removeInventory, and addInventory methods. I also added an unauthorized 401 response for each of the three methods for token authorization. However, I wasn’t able to fully implement token authorization to the API since Mike wasn’t able to finish work on the tokens.

This sprint, I feel, was messier than the last two since our team was mainly trying to finish up what we had leftover form sprint two and do whatever we could before the end of the semester. It feels like that lack of direction was one of the factors that affected the rate at which I performed my tasks. I already mentioned what I did during the sprint which I think isn’t really nearly enough of what I wanted to do. I wanted to finish up what I had leftover from last sprint in a week or two and completely focus on the event system and maybe help out on the backend functions. What ate up most of my time was trying to test the API with docker which I wasn’t even able to do in the end. And I couldn’t even take advantage of the extended deadline since most of my finals were on the week following the new due date. I was only able to make the subdirectory and the basic send.js file during that time span. What I’d want to improve on as a team is to set a clear goal since I feel that was one of the factors on why I think I wasn’t able to do as much as I wanted to similar to what I said last retrospective. As an individual, I really need to brush up on docker since I couldn’t test the backend correctly even though I based it on the stoney-manage-items example on GitLab. I couldn’t even get the example itself to run on docker either, neither locally or with the docker-compose.yaml file.

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

The Final Sprint Retrospective

The most headway came when multiple sets of eyes were on issues. This first proved to be true when the IAM System Community of Practice was working together to establish the logout functionality and to ensure that the user sessions properly expired to prevent unauthorized modification of the database.

This also rang true when Tim Drevitch and myself were finally able to free up time and address out standing issues. As per my comment here, and his comment here, we were able to spin up a docker instance of a database and pretty quickly figure out how to start adding to the database just shy of setting up the specific documents we needed to store individual users/entries. It was three hours of troubleshooting together, researching different aspects, and then explaining them back to each other over voice chat, but we made substantial head way where there was otherwise none (despite it not being a card assigned to either of us).

While there are obvious constraints to having green undergraduate students try to develop software on a very part-time basis, it became very obvious that not all the teams were created equal. When I would meet with the IAM community of practice we would discuss what our groupmates needed of us and I would routinely report back to them that my group had made no mention of any code, functions, methods, etc that they needed from me nor intended to integrate any time soon, much to their surprise. This signals to me an overall unfamiliarity with the tech stack which is not a judgment on them, they’re doing their best given the limited amount of time in the day and the craziness of navigating online learning. That being said it was often the bottleneck within team discussions.

What was within teammate control and —seems to be the modus operandi students within the Worcester State University Computer Science Program— very unacceptable was the lack of communication. I would consistently ask teammates what they were working on and how it was going only to get no response. In fact, there was one teammate who I had never heard talk until three weeks until working with them; it’s anyone’s guess as to why, but my experience with my fellow computer science students has been largely marred by radio silence. My biggest change I would have made to the team was to force my teammates to communicate by instead of asking them “what is stopping them” in the standups, ask them “what is something they encountered that they didn’t understand while they were working”.

My personal failings in the last sprint came largely from my pivoting away from schoolwork to build out skills that would help me attain a summer internship as well as applying to said internships. I became more focused on learning the practical skills gained from sites such as and studying for the eJPT certification so that I may pursue a career in information with an emphasis in exploit development and malware reverse-engineering. My ability to engage with school work may have declined but it was a necessary sacrifice to (hopefully) make myself a more viable job candidate.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective III– Reporting System

I am part of Reporting System group in this project and my job is to support and secure other system through keycloak. It is a 5-person team, and my part in this group is to implement a third-party system (KeyCloak), deploying the system (using docker) and help other system by embedding in their teams. Also help with other team tasks other than IAM system.

What I think that worked well in this sprint was that we were clear on what to read and what to look for. We understood the instructions and started the work that we thought it would be useful for us to know and learn. I was able to make some progress and secure the backend and have a better understanding of the tokens. Created a realm for the reporting team and added their users. This link is a good source for anyone who is new to Keycloak and wants to know how it works. There is information for everything you might need with keycloak.

I feel like for each sprint our group is getting better in understanding the requirements and what needs to be done so everything went okay based on the plan. The only thing that I was not able to do in this sprint is to have the keycloack updated with the team frontend and backend. The reason for that is because team was working until the final day before our retrospective and we didn’t have time to try it out and the issue was pushed for next sprint.Again, overthinking some basic stuff that didn’t need a lot of time spending on it continued in this sprint too.

I think in this team I feel comfortable and able to communicate openly with my teammates. Most of the time we spent it working individually or in groups of 2-3. In this sprint we made a lot of progress and created some important part of our system. Not all issues were done by the end of the sprint but we did cover some important ones.

As an individual what I could have changed is helping my team more in other issues too and discuss the problems with my team.

In this third sprint we had enough issues for a team of 5 people. Most of the issues were about building frontend, backend, and figure it out how to make the reporting system work. Issues were mostly individual but also, we had ones that we developed in group. I was assigned to find and understand tokens better and securing the example backend through keycloack. I was able to finish both issues with success and the one that were in group too. Created a project file with all my documentation in GitLab with steps I followed, to complete the work I was assigned for.

We all wrote our descriptions on the issues, what we learned and how we are going to use it in the future. The link is provided in GitLab so anyone who comes after us or want to check on what we did, can use it, and help the others too.

Read the file in the project to follow the instructions. Overall, this sprint was better than the first and second one and we got result. If the first one was trying to understand what was happening, this second sprint was more hands on the deck sprint and the third one was makes things happen.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Photo by Tim Gouw on

For the final stretch of our allotted development time working with the InventorySystem component for the Thea’s Pantry project, we focused largely on getting all the frameworks (frontend, backend, database) into a functional state for the next team taking over on the project. I focused much of my time on getting our frontend components pushed to the container registry for the project on Gitlab:,

Originally I had wanted to implement automatic uploading to the container registry using a Gitlab-CI file, but encountered numerous issues related to the file-structure of our frontend projects, Gitlab’s continuous integration system not being able to find certain files, and problems during the build stage throughout the deployment process. As a result of this I eventually decided on using Docker-Compose to push the components to the container registry. While this won’t be able to execute automatically in the same way as a CI file, It was more important to have working containers pushed to the registry for the next team to be able to work with.

Throughout sprint #3, we were able to finish off some of the outstanding issues which were leftover from previous sprints, we finalized parts of the backend framework and implemented partial functionality, finished setting up all three frontend frameworks for future polish and development , and were able to implement a basic database for storing inventory-weight, as well as some further polish/refinement of the API

Additionally, one team member worked on the Identity Access Management system used for the project, Keycloak, and was able to create working frontend and backend environments for using the system to verify users/determine whether someone has appropriate permissions to access certain pages/fields: Everyone seemed to accomplish a lot this sprint, and I think that we were able to leave the InventorySystem at a good starting point for the next group of people who end up working on it.

If I could have done anything different, I would likely have spent more time on trying to get the CI-file working as intended, as automatic integration/deployment of the project would be more convenient for developers than having to manually push to the container registry each time changes are made. Also, I think that the Vue components for each of the frontends I worked on could have been polished some more (add features such as slideshows, responsive page design, stylized buttons/appearance) but those would very much have been low-priority issues to be focusing on.

Each of the three sprints had different focuses, with the first sprint being focused on learning the tools we were working with, and the second sprint being centered around building the foundational aspects of the project as a framework for future functionality and development.

This third sprint felt like finishing off all of the frameworks, some polish, and getting everything ready to be worked on further. I think that we accomplished a lot as a team over the course of around three months; this was a great learning experience which felt essentially like working in a professional development context. I look forward to the next opportunity I have to work in a similar environment, and wish my teammates well in their future endeavors.

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

Sprint 3 Retrospective

It is hard to believe that I am writing the final blog post for my capstone already, it feels like I was feverishly reading through Keycloak documentation only weeks ago. This final sprint did not exactly go according to plan, but I am not entirely upset with the results. Overall I felt that my team did well on this sprint, but again felt like I should have been further ahead on my own work with the IAM System to allow myself to help more with the Inventory System. But there was some needed bug fixing and research done into different aspects of Keycloak itself that should be helpful further down the line.

As stated, I felt as though the Inventory System team all seemed to make steady progress in developing the different parts of it. There was progress made on the API in addition to the various front ends needed for the Inventory System and it seems that there is a whole skeleton system now in place that can be iterated on later. As for the work on Keycloak, when meeting with Cam and Migena we managed to work out some errors I had made in the setup of some attributes needed to connect Keycloak to Professor Stoney’s basic front end. In addition to this, we discovered that our Keycloak docker image could have a backend with persistence set up relatively easily, with a variety of choices listed here The other major focus for myself this sprint was on figuring out how to get user information from tokens by making calls from an Open API, as I knew this would be needed for implementing Keycloak into the Inventory System, and potentially others. In doing this I did manage to get authentication tokens, but did not make more progress past this. Once again I felt as though none of this should have taken as long as it did, throughout the sprint I feel like I would get bogged down by one issue and could have handled this a bit better.

I feel as though there are not many changes that could be made for our team to improve, as we simply ran out of time to start compiling all of our work together. As stated I feel like the Inventory System team did get a significant amount of work done, but there just was not enough time to truly start to work together with all of the different systems we had worked on. As for my own performance, I simply feel like I could have done more had I spent more time working. Time management has been a skill I have slowly developed over the course of my time at school, and it has certainly come a long way. That being said, there were still multiple times this sprint where I could have buckled down and simply focused on getting more work done. In summary, I feel as though the work that was done will provide a solid foundation that can be expanded on, but could have been fleshed out a little more had I managed my time more efficiently.

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3 – Thea’s Pantry

The third sprint went fairly well. For the third sprint I did most of the backend from the get request endpoint to the response that returns the CSV report. To do this I first created the endpoint which gets two query strings from the request: start and end date for which I use as a date range for the data to put into the report. I then send the query strings over to the Report module which has all of the functions to create the report. In this module I first turn these query string dates into ISO dates and then query the guest and inventory data collections for any records between those dates. Then I make it search both object arrays returned by each collection for matching IDs and merge each of those objects with matching IDs into one object in an array. Then, turn that object array into a string with CSV format, have it create a file once that is done with the CSV text, and send a response back to the front end with a download of that file. After creating methods to do all of that, I connected the backend with Haoru’s beautiful front end and tested the system fixing any bugs.

What worked well this sprint was my gained knowledge and experience with Node.js and MongoDB. This allowed me to complete more complex operations with them and create what was needed. Because of this, I was able to finish most of the backend conforming with most of the requirements. Also what went well was how smoothly it integrated with Haoru’s front end, only needing a few tweaks, I wasn’t sure what to expect initially.

What didn’t work well was our teamwork. I would say that our teamwork depreciated since our last sprint due to the amount of work that was needed to get done. Since we all had stuff to do we didn’t have much time to merge everything together. For example, Derin worked on dockerizing our application, but needed more discussion to put it all together than either of us had time to give. Another example was with Migena’s keycloak system, where again, there wasn’t enough time to merge with the main application. Our production was higher than last sprint but at the cost of communication.

What we could have done better as a team was time management. Since we sacrificed how much we got done last sprint in order to work on teamwork, we had a lot of work to do this sprint. If we had organized our time a little better we could have had more time to combine our work this sprint and as a result would have a more complete system.

What I could have done better this sprint would have been to take some extra time to work with Migena and Derin. We came very close to our goals for the end of the semester, with one more sprint I believe we would easily have finished the base idea of what the system would be. Although I was very busy with the backend, I’m sure it would have been doable to combine our progress if I we took an extra 2-3 hours over the course of the sprint. – link to the main application with the modules spoken about in this post.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.