Category Archives: Sprint-1

Sprint Retrospective- IAM system

I was part of IAM System group in this project and my job is to support and secure other system through keycloak. It was a 3-person team, we are going to implement a third-party system (KeyCloak), deploying the system (using docker) and help other system by embedding in their teams.

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. There is a lot of documentation online for KeyCloack, how it works with other system, with docker, examples that we could try etc. 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.

https://www.keycloak.org/documentation

Something that I would say it didn’t work well in the beginning it was the amount of information we had to learn and go through. Because this was a project that was new to everyone, we were kind of lost in the beginning and placed issues that weren’t necessary or missed issues that were necessary. It is risky when you are introduced with a new tool and you get lost in the sea of information. Also, we tried to learn tools that we didn’t need it, or we were overthinking some basic stuff that didn’t need a lot of time spending on it.

What we could improve like a team was working more together. Most of the time we spent it working individually and sometimes we were not on the same page. Also, we could have found more examples online or use work from other classes that were close to our project and practice on those during class time. We were focused more in the GitLab board and finding issues than working in what we had and making something more concrete than documentation. Also, when we assigned issues, we could have left it unsigned, as long as, all issues were done by the end of the sprint.

As an individual what I could have changed is being more open with the team and discuss the stuff that were bothering me rather than avoid it and try to hide that I didn’t know how it worked.

In our first sprint we had enough issues for a team of 3 people. Most of the issues were about introduction to Keycloack and figure it out in theory how this system would work with our system. Issues were mostly individual but also, we had ones that we developed in group. I was assigned to getting started with keyclaok which was in group, the authorization services which is an issue that I continue to work on, upgrading that is a closed issue because the way we are going to use keycloack we don’t need to upgrade it and connecting with reporting system to help them in making keycloak work with their system.

We all wrote our documentation 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.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/iamsystem/community/-/wikis/home

To the right side of this wiki page there are all the documentation present that me and my team wrote about in this blog. Overall, it was our first experience and it was more like a sprint practice to be ready for the next one.

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

Sprint 1: Retrospective

If anything can be said about this sprint, it is that a lot was learned throughout. I was familiar with how the teams would work, but many of the day-to-day specifics and exact deliverables were a bit unclear to me. Before this class I had only really examined this sort of team structure in CS-348, and that more theoretical practice left me in the dark on some of the specific aspects. To specify, the issue board for our team was not utilized to its full potential in a few different ways. However despite these issues we were able to complete all issues on the board. First I will discuss exactly what worked well, and subsequently what did not.

Regardless of what could have been improved, which will be discussed, this was overall a successful sprint. Each team member did, at the minimum, read through the material they were assigned and documented any relevant information in the wiki. So by definition this was a successful sprint, but it’s true value for us was what we learned for the next sprint in my opinion. One part that could have been worked on were the actual issues themselves. These could have been streamlined a bit, as we simply decided to read through all of the documentation because it was the most logical thing to do. However the documentation often contained much superfluous information that may not really end up  being useful. It felt as though this was mostly being done to meet our SCRUM goals. Besides this, it was still difficult to communicate all of this information with each other. Throughout the sprint we also forgot to move issues through the board as we worked on them, and I personally did extraneous work that could have qualified as a new issue but did not think to create one for them. After all of these issues however, there are some changes that can be made for this next sprint.

This first sprint was an extremely valuable learning experience as previously stated. There are a few ways that our community of practice could improve the effectiveness of our teamwork. One idea that was brought up was to simply communicate more often using the community of practice channels. This will allow us to simply have one location containing all information we may need, and allow us to be on a similar page with each other. To further improve this, we also discussed having small work sessions in the community of practice from time to time to ensure none in the group are behind. This would also allow us to have more consistency in the method that we use to connect our respective systems to Keycloak further down the line. As for myself personally, my major flaw was simply getting behind on my work. If I am being honest, I had to do much more reading towards the end of the sprint than should have been necessary. To improve on this, I have set aside specific time frames during the week to work on projects. I will also try to share any more useful information in the project-wide community of practice, as I have a tendency to just share information in my team’s text channel only. I am excited to put all of the changes into play for this next sprint!

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.

CS448 Retrospective Blog #1

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/8

Here I put links for tutorials and relevant articles for learning MongoDB.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/27

This card shows I was allocated to the event system cross-cutting team.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/16

This is a card I created for learning how to connect the backend to mongoDB.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/18

This card is for an example mongoDB project.

Our first sprint was filled with learning, both about the tools we need and about the sprint process. I think there are many things that worked well. First, I think our team composition right now is good. We all know each other from previous classes, and we are comfortable with talking casually to each other. This is good because there was no initial awkward phase – we were able to get straight to working with each other. Another thing that worked well was asking important questions for each other on gitlab. While we did not use the cards to their fullest potential, having email notifications for gitlab really forced me to pay attention to the cards. My discord does not have notifications turned on, so I must actively check for new messages. On gitlab the email notifications made me extra aware of new comments on cards and any changes to the cards.

There were of course many things that did not go so well. Somethings I failed to realize is that gitlab should be the place where I keep all my work. I followed quite a few tutorials, so I have a few mongodb projects on my own computer. I should have been actively adding them to gitlab as well. My issue was that I did not feel like I had a finished product worth sharing. I should have realized that was okay and posted that anyway.  Another thing that did work so well was communicating mostly on discord. We did a lot of brainstorming and communicating in class through voice chat. Because we did not write down every single thing we spoke about, some things were forgotten or missed. We should definitely be trying to use text chat more, but most of our communication should probably be through gitlab to maintain a permanent record of what is being discussed.

As a team we should definitely work on mostly using gitlab cards for communication. As a team we should also try to contribute more evenly in discussions and with product owner meetings. I know I am not contributing enough and we should all be taking responsibility for our team instead of just letting one or two people do all the talking for us. Overall though I feel like my team is very solid and we work well together.

As an individual I should work firstly on time management. Having sprints like this is almost deceptive in a way. This isn’t the kind of thing you can do all the work right at the end of the sprint. It really isn’t possible to complete most of the cards like that. The work should be spread out, especially since it is cumulative. Some cards need to be completed so you know how to complete other cards. I also have to work on communicating with my group more. As the system is more fleshed out, we are going to have to work together more to combine the parts we have created. Right now we are sort of working independently and just checking in with each other. I will have to share the work I am doing with he rest of my team very frequently by pushing it to gitlab instead of just waiting to show them during class.

I went into this sprint very intimidated by the size of this project. After finishing it I feel a bit better because I know how sprints work now and we have a clearer vision of what we are going to do for this project. The next sprint will definitely be an improvement over our first.

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 #1 Retrospective Blog Post

After the first month of my final semester, my capstone course has proved to be an interesting experience so far.  As much as we are working in groups to create a database dedicated for the food pantry, I believe we really are striving to strengthen our skills with using the SCRUM method of group work.  Our first sprint went very well in my eyes.  We have not gotten much done in terms of making the frontend and backend of our database, but we accomplished a lot when it came to getting tasks done that we chose to try to complete at the beginning of the sprint.  Our team worked very well together and it seemed as though everyone was contributing heavily towards finishing our tasks quickly and completely.  Personally, I thought I contributed a lot of research, work, and extra effort for the team to help everyone out.  We decided to make me the team’s SCRUM Master which in all honesty did not force me to have much more responsibility at all, but it was helpful for me to learn from the product owner and relay back to the team.  I tried keeping helpful information posted both on discord and on gitlab for the team and for myself.  This proved very helpful.  In the future (for later sprints and for in similar situations in real life), I believe we could have done a better job communicating outside of our class periods.  It may have help our group get things done even smoother than how we already did if we had been running a better communication system.  This however was not really anyone’s fault as we were still able to get most of our tasks done and because of the fact that everyone is taking a lot of classes right now and not just this one.  On a personal note, I think it would have relieved some stress for me if I could have tried spacing my work for this group out throughout the week rather than getting things done in one or two sessions per week.  This would have made it easier for me to communicate problems if I had had any and would have reflected better on my final completions at the end of the sprint.  Again though, it is more difficult when I am taking other courses and not having this project as my main job or focus.  The main issue that I think my group and I will run into for the next sprint is that we will have more tasks related to building the database now rather than the more learning and reviewing bases tasks we had in sprint one.  Like I stated earlier, this sprint seems more like one in which we get familiarized with how the rest of the sprints will be done and how to work as a group with SCRUM.  However, I think we picked up on what we needed to do very fast, and everyone seemed to have put in a lot of good work and dedication.  Because of this, I know that even if the tasks in the next sprints become more difficult, we will still be able to get great work done and have a successful product in no time!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Thea’s Pantry Sprint #1 Retrospective

Sprint #1

Photo by Pixabay on Pexels.com

For our work on the InventorySystem component of the Thea’s Pantry software project, our team worked throughout sprint #1 to learn about necessary tools, skills and technologies which we will be using throughout our development of the project. This meant that a majority of our focus was on learning, although a small number of useful artifacts were also produced. Much of our communication throughout the sprint was coordinated with the issues board for the project on GitLab (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/boards) which allowed us to keep issues organized based on whether they were actively being worked on, completed, or in need of review.

More specifically, much of my work during the sprint was focused on learning about the Vue.js front-end framework. I organized this process into a number of issue cards, with one central card (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/2) which I used to connect three interrelated cards concerning the same topic.

First, I went through introductory content (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/3) from sources including the official Vue tutorials on the website for the framework, as well as introductory materials produced externally, such as this intro to Vue 3 series: (https://www.vuemastery.com/courses/intro-to-vue-3/intro-to-vue3/) produced by Vue Mastery.

Furthermore, I went through some of the most important highlights of the Vue documentation to learn the fundamental concepts of the framework (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/4), and then practiced using Vue by building a simple Docker container with a Vue Installation (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/5).

Combined, I feel that this sequence allowed me to gradually build up a familiarity with Vue and to become fairly confident overall in my ability to work with it. When the group begins working on the actual implementation of the front-end during the next sprint, I will be prepared to make use of Vue for the creation of the three different front-ends necessary for the InventorySystem portion of the Thea’s pantry project.

In regards to how this sprint went overall, I would say that it went relatively well. We managed to complete the majority of the work which had been staged for completion, accumulated a lot of valuable information, and built a wiki for the project (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/wikis/home) which we can now use in the future to store documentation as well as the sort of syntax/procedure which we focused on during the sprint. Everyone on the team was able to find a large number of resources, tutorials, and documentation related to their chosen topic/focus throughout (ie: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/6, https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/10). Additionally, we were able to get the basic structure of the project setup (multiple repositories to hold the corresponding front-ends, the back-end etc) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/14, https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/13).

One minor issue we did have was in relation to the database/data persistence layer of this project. We didn’t have enough people allocated to the team for someone to focus on learning about MongoDB (the database software being used for this project) specifically. Given that the front-end and back-end were deemed the most important components necessary to get started with actual development & implementation, we decided to focus on MongoDB during the next sprint, after we have some of the front-end and back-end frameworks implemented and in-place for the database system to hook into.

In conclusion, I would say that the sprint was a success, a good majority of the work planned was completed, a great deal of information which will be useful in the future was collected, and then categorized/organized on the project wiki. The example project using Vue and Docker will be an important reference during the next sprint when we will need to begin working on the implementation of the project, and we will be ready to start working on the functionality and layout of the InventorySystem during the next sprint period.

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

Sprint 1 Retrospective

Wiki: https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/wikis/home

For our first sprint, we mostly focused on learning what we need in order to build the inventory system such as Vue.js, Express, and API. I worked on researching Express by finding, studying, and recording resources such as Express tutorials and syntax guides among other sources. I also got in some practice writing and running Express JavaScripts, though not as much as I’d like to since there weren’t many examples I could find online. The team also created repositories for each component of the inventory system and a wiki where each member can place links to helpful resources. The link to the wiki, which include the resources on Express that I found during the sprint, can be found in the link above. If I were to describe what worked well, I wouldn’t know what to say since this sprint focused on learning rather than building. The same also applies for what didn’t work well since components can’t work incorrectly if you don’t build any.

Overall, I feel our team did fairly well considering one of our team members was incapacitated for a good amount of the sprint. We were able to finish tasks that amounted to 13 weight out of the tasks planned that amounts to 18 weight. That’s six weight for each remaining team member with one extra. The only thing I remember the team really struggling on was getting used to working in the structure of a sprint. So, I can’t really think of a way the team can improve outside of getting use to the workflow and structure of a sprint. It’s about as specific an area I can think of for improvement and it’s a pretty general area. And when I talked to my team in our sprint retrospective, they couldn’t think of much to improve on as a team either.

However, I can think of a bit more to say if we’re talking about what to improve as an individual. For example, the entire sprint I had a general feeling that I didn’t have a clear goal in mind outside of “study Express”. This probably resulted me to not have as fast of an output as I could have and also caused me to worry more that I wasn’t doing enough work. It’s also one of the major reasons why I couldn’t practice writing and running Express JavaScripts as much as I’d like to outside of the other reason I mentioned earlier. Another area I could improve on is summarizing the outcome of each task assigned to me. I say this because I didn’t realize I was supposed to do this until the meeting near the end of the sprint. But then again, this issue kind of ties back to what to improve as a team; getting use to the workflow and structure of a sprint. So, all I can really think on what to improve on as an individual is planning on a specific goal for each sprint to give a clearer direction and remembering to summarize the outcome of each of my tasks.

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

Sprint 1, a Retrospective

Mired by a litany of confusion and growing pains our group managed to come out on top. Actually, that is a boldfaced lie; our group disbanded but I assure you these two things have little to do with each other! All joking aside, our plan at the outset was to learn about utilizing the information access management software known as Keycloak. As it was our first sprint working with completely unfamiliar technologies, the sensible thing seemed to be to read the darn manual and document our findings. While this worked for reinforcing our individual assigned topic from the official documentation, I have to wonder if it really helped us deliver a tangible product or just slowed us down. To elaborate, it seems as though we read a lot about the technical aspects of Keycloak but at the end of the day there was little to analyze and report other than that the documentation seemed to be thorough. In hindsight, I believe the better approach would have been to work together as a group and walk through the configuration process, documenting the whole thing. Moreover, we should have raised questions about the size and scope of user volume and based on those factors decided on a configuration (cluster versus standalone comes to mind) to attempt. While configuring Keycloak and WildFly on our local machines certainly gave us insight, we would have discovered that learning about WildFly and its subsequent installation may have been completely pointless depending on which configuration we decide on going forward.

Given our approach I found that the best work was done when we were collaborating together. I touched on this concept earlier when I was describing how – with the benefit of hindsight – our group ought to have approached the assignment, but synchronous communication and action taken towards configuration yielded drastically better results. It was during these sessions where the team was able to best overcome technical hurdles (such as versions of Docker mismatching) or discover some steps might be superfluous (such as installing and configuring WildFly when not using a local instance of Keycloak). It pains me to say it but it seems as though, of the work we got done, a very small portion of it ended up being useful and that our approach seemed to be driven more by how we could fit our work into the agile framework and not how the agile framework could best help us implement our work. This isn’t to say the framework is of no value or inherently a hindrance, nor is it an indictment of any particular person, but it seems as though our group was not able to mesh well with the framework to get results.

Individual improvements can mostly be derived from the same tired critiques in the vein of rugged individualism whereby things such as losing power, health problems, email harassment must not dampen one’s spirit and certainly, above all else, not their work ethic. Perhaps if I had instead made a measured effort to calculate how many hours of autodidacticism I could throw out so that I may stay in the low C range (as opposed to the upper range) of a non-major class, I may have been able to find more time to commit to exploring Keycloak. Is it unprofessional for a student like me to complain on an assignment for my personal blog? Perhaps. I would argue it’s at least as unprofessional for a teacher to underperform in their profession and that students should have to internalize that as an individual failing.

Links to work done on our team’s wiki:

This wiki entry is the reference page I accidentally wrote on the Authorization Services.

This wiki entry is the reference page I created for WildFly.

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 1 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/14

This was easily accomplished by everyone. This was learning the issue board.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/1

This was us choosing a Scrum master. We decided on Tim Drevitch.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/25

This was our review of the LibreFoodPantry website which was to get an idea of LFP.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/24

This was creating the requirements for the GuestInfo EventSystem, in which I linked resources and described the requirements.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/9

This was the most time-intensive task. I linked multiple tutorials for Vue.js, all of which I completed. This encompassed most of the first two weeks of the sprint for me.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/17

This is the repository I made which contains all of the simple examples we created for small Vue.js, Express, and MongoDB applications to pull from.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/26

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/13

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/11

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/12

These 3 activities are encompassed in the GuestInfoSystem section of Thea’s Pantry. There is a repository for frontend and backend work. It has basic files for each which is taken from the WNE example.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/15

This is created a sample Vue.js project, which is on the example work repository.

            Overall, I think we worked quite well as a group, and I would attribute a good deal of it to how well our sprint planning went. We were thorough in going through topics which we felt we needed to cover and created individual cards for everything so that all of our tasks were tangible. Furthermore, we were fair in our division of labor and honesty in what we wanted to do while still taking on enough responsibility as individuals to support the team as a whole. What worked well towards the end of the sprint was also when we focused on what we hadn’t yet finished and allotted the work evenly. Not only this, but we had also made enough progress that I found it to be helpful to have a sort of progress report session in class. We were going through with our Scrum meetings daily, but it was more in-depth, and we were able to articulate what we had done and where our progress was taking us. This was very helpful and perhaps we could incorporate this into our Scrum meetings, allowing us to have a better stream of communication.

            There weren’t many things that didn’t go well for us, but a few include some lacking communication at times and a lack of due dates. As I articulated previously, I was only able to notice any lacking communication when we did communicate better. It wasn’t that our communication was impeding our progress, but it definitely helped to have a clearer picture of the project as a whole when each of us was clearer about our individual progress. As far as a lack of due dates, we became a little rushed towards the end of the sprint since we spent a little too much time completing our learning tasks. If we set limits on these tasks, because they were more open ended, we could have gotten some of our more rushed late sprint activities done faster.

            As far as changes to be made as a team, I would focus on making the changes I stated previously. To get better communication, we should make better use of the cards on the GitLab issue board. Each card should have documentation of information learned and progress made it on it. This makes it much easier for everyone to read the cards instead of having to check Discord or wait for the in-class meetings. Also, we should start putting due dates on the cards for our own sake. This would keep us on track better.

            Individually, I should plan out my time more. I was feeling lost with Vue.js so I spent a lot of time on it. I got into stuff that, later on into the sprint, I found out that I didn’t even need. I need to be better at setting due dates and creating more incremental tasks. I took a couple longer tasks and rather than breaking them down, would try to accomplish a couple things at once which could have been subdivided. This, along with better documentation on the GitLab cards, should put me in a better spot for success in the next sprint.

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

Sprint 2 Retrospective

This past week was the end of our second Sprint for the Capstone class. It all went well, and I think we completed all out tasks successfully. I will write about my tasks and my overall impressions of this Sprint.

Tasks:                                                                                                                                                                

  1. Issue #25: Connection between Database and Rest API Backend
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/25
    Creating a Rest API backend that talks to the Mongo Database with specified queries and retrieves total weight.
  2. Issue #2: Fix CI Setup
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/CheckoutService/-/issues/2
    As the name implies, fixing the CI/CD setup for GitLab pipelines, after copying from master it no longer worked.

What worked well?
This time around the Sprint and our lives in general were drastically changed due to ongoing COVID-19 outbreak and the implementations of federal emergency and stay at home orders. It all began normally we started this Sprint like we have before with everyone working on our tasks and meeting once a week for a group session to tackle the problems together. After the outbreak what worked well was very little. In my case finding time and just organizing anything due to my work switching to a “work from home” situation was extremely challenging. One thing that might be working in our favor is that due to most people not working we can call in an online meeting a lot easier since we are all at home. There will still be some time constraints of course.

What didn’t work well?

The social distancing order is a little challenging to work as a small group like this on a project. Before we were able to meet and collectively challenge some of the problems we were having. Scheduling some of the meetings got easier but the actual work time got drastically reduced and in my case just being able to perform some tasks is rather challenging.

What changes could be made to improve as a team?

As I have mentioned before, as a team we should work more on our comments and notes when it comes to working on GitLab and making sure that future participants will be able to trace our decisions and thought process, I believe we are simply not there yet and Corona Virus outbreak made that so much more challenging than before. We also should work on our problem descriptions, we need to be more specific and detail oriented, in my opinion we have only used more generic wording. We probably should have broken the bigger tasks into smaller sub-tasks to make them more approachable as a whole.

What changes could be made to improve as an individual?

During this sprint I have again felt that I have not contributed enough to the team, the tasks I have performed were not as hard as they seemed originally, only working on the API connection to the database took a significant time. As an individual I also think that I should work on my free time management and schedule conflicts. I work full time and often I have only certain time frames to work on school projects and homework and with the temporary adjustments to our living conditions that has gotten even worse. This time will be a real test for all of us, test of our self-control and patience.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Sprint 1 – Retrospective

Sprint 1: 01/22/2020 – 02/19/2020

During the month, I started to work as part of the UpdateGuest time for the LibreFoodPantry project. The Sprint started with sharing and learning general knowledge about the project, what are the services to be offered, and some future perspective. As I learned the service that I and my team will be supporting, we began to fill the backlog with to-do tasks. We operated as a Scrum team, managing a Scrum board in GitLab, and separating stories based on requirements.

We started this sprint by learning new knowledge. As we decided to with the MEAN Stack, we needed to gain knowledge in all technologies that will be used: MongoDB, Express Framework, Angular, and Node.js. So we created stories to track our learning timeframe and weight the knowledge we gained.

During the Sprint I worked in multiple stories and supported the team in different topics:

  • #1– I created the Angular App, the Mock version of our UI service. I supported the team with discussions on how the App should be implemented and organized.
  • #2 – I supported to edit and fix an issue we had with .gitignore file. Together with the team, we discussed how to fix this issue and concluded with a good result.
  • #3 – I created the Document and designed the Frontend Architecture for out UpdateGuest. This document will support the implementation of the service. This document will be edited during Sprint 2
  • I supported the team with PR reviews, issue discussions, and research when we had knowledge gaps.

The end of the first Sprint consists of secure knowledge and the beginning of work with UpdateGuest service.

In this retrospective, I and my team need to reflect on these points:

  1. What we need to stop doing
  2. What we need to do less
  3. What we need to keep doing
  4. What we need to improve

1- What we need to stop doing

We should stop Approving PR by only one person. Each member of the team should approve a PR – so we know that we are all on the same page.

2- What we need to do less

We should be careful when we create new stories and check if there are no duplicates.

If there are duplicates, before closing the story we should let the creator of the story know first.

In the case of merging a PR, the creator of the PR should merge, or if another person do it, we should let the creator know first.

3- What we need to keep doing

We need to keep working with stories that we have on the Sprint backlog.

We need to discuss issues that we may have during the sprint and approve each other work.

We should keep reviewing each story before we mark them as DOne and close them.

We should keep solving debatable conversations and conclude in a good result that works for everyone.

4- What we need to improve 

We should have better communication for each story, issue or blocker during the sprint. Class meetings are not enough to solve issues. For each story, we all need to discuss and communicate with each other, and to consider all opinions before we conclude to a solution. Communication is the key to success for a team.

Conclusion

As a team, we successfully closed Sprint 1. We closed most of the stories in Sprint’s backlog and supported each other to move to the next sprint. We had a Sprint review for what we did, and a Sprint planning for Sprint 2, so we are prepared for the next step. So, let’s start implementing our ideas!

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