Category Archives: Sprint 2

Sprint Retrospective – Sprint 2

I think that we as a team, as well as me as an individual, improved during this sprint compared to the first sprint. While for the first sprint we had no experience working with scrum sprints or in any sort of team development environment, so the whole thing was completely new to us, whereas at least now with the 2nd sprint we had at least a tiny bit of experience. This means that we were able to improve upon some things from our first sprint, because we could see what we did wrong and could change our plan in order to avoid our previous mistakes and optimize our workflow overall.

The first thing we optimized and improved upon was our sprint planning. From our first sprint, we could better judge what we could get done during a sprint by how much we got done during our first sprint. This way we could efficiently work on items, getting as much done as possible during the sprint and not assigning too much during the sprint to the point that we end up not getting most of it done. We could also better assign weight to each of the items because we could better judge how long it would take for us to get each item done, and better judge the importance of each item to the overall project and current objective.

The second thing we optimized and improved upon was our overall communication. We still did most of our communication in class, but we now made sure to communicate through the issues on GitLab. When an issue required additional clarification or explanation, we could leave a comment on an issue and ask the creator of the issue for more details, and the creator could easily respond right on the issue. This not only improved upon the frequency of our communication, but it also helped us to differentiate and easily see what string of communication was pertinent to what issue, helping other team members to see what was discussed respective to what issues. This way, if a team member was working on an issue similar to or previously worked on by another team member, they could easily see what kind of issues that team member faced while working on it, and that could help them work through it without even requiring more help from the team. This makes the workflow as a whole much more efficient because any communication is saved, categorized, and easily searchable.

For the team as a whole, we could still improve upon our communication. Although it is efficient communicating through GitLab issues, and it does have some benefits, it is also good to have some non-official communication that doesn’t directly relate to a particular issue. Leaving this communication on GitLab would be messy, so it would be better if we did this additional communication through discord. For me as an individual, I think I could’ve helped more with the sprint planning, and better assisted my team members. For the spring planning, I could’ve better helped with coming up with weights for issues and assigning them. Finally, I could’ve better helped my teammates by being more active responding to open issues with comments and helping them finish open issues if I’m done with all of my issues.

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

Sprint Retrospective 2

By this sprint, everyone had an idea of what they were doing and what needed to be done. So everyone was on track with required workflow. In this sprint, people started to add issues of their own. I should have added issues I found in this project, but I just discussed with the team members, and they added it. Overall, for this sprint, I have a mixed feeling about it. I felt as if I didn’t do much help to the team, but at the same time I felt like I gave my all to the team. I did solve a couple issues during this sprint.

The first issue I solved was simple enough that I forgot to add it to the project issue board. Logically, it made sense to fix this issue so that the form doesn’t become annoying to the user. Imagine clicking on the input field every time the form loaded. So guest 1 comes and swipes, guest 2 comes then you have to click on the input field, guest 3 comes click again. Doing that over and over again would have been exhausting. I didn’t really notice this issue until I tested the code with card reader. At first, I thought I had to write some method so that the text would automatically focus on the input field. I was lost and had no idea about how to make it work. At the end, I felt really stupid because the solution was simple, and I was overthinking it. The solution was in the HTML input attribute type. All I had to add was “autofill” in the input attribute. Refer to this commit. Here

For the second issue I fixed, it really took the best of me and my time. My goal was to on a click of a button which is in one of the child component in Vue, I had to get the data from localhost, store it as an object then pass it to another child component so that those data would automatically fill the form. Sounds simple and easy. But the thing is, you cannot pass data from one child component to another. So the process was to get data from one child component, pass it to parent component using emit and then pass that data to another child component from parent component using props. Michale had already passed the data from component to component and I thought it would be relatively be the same. I couldn’t be any more wrong. I did everything same as Michale and everything worked as we wanted. Since our API was not fully done, I tested my method using Jsonplaceholder and sent the data to another component. I put the Jsonplaceholder’s ID number as a zip code, and it displayed as I wanted it to be. The major problem was that I was using options:Lifecycle that would assign the data before the form loads, which leads to not being able to edit the form data. Removing the lifecycle and just mounting it to v-model worked, but it rendered the first child component twice in the same page. Other than that, everything was working. I was able to get the data, pass to the form and edit then submit the edited data. I am not really sure how this worked, but to fix the issue of rendering the component twice, I hid the first component when the submit button is clicked. After that, everything worked as we wanted. Refer to this commit for code details. here

On to the third issue, when swiping the card, the input field only picked up the correct ID on the first swipe only. This issue was taken by another teammate, but since he wasn’t able to complete it, I took it from there. After a couple of hours of debugging, I was left with nothing. I understood the code the previous developers left, but I wasn’t sure why the issue was as it is. I started to think that if it worked on first swipe, let’s make every swipe as first one. So the solution was simple. Refer to this commit on line 93. here

This Sprint showed who is really dedicated to the project, who is really passionate to the software developing. It seemed as everyone was giving their 100% effort to the project and were all liking the process. I don’t have a single doubt that we won’t be able to finish this by the end.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

With our second sprint concluded, our team made significant progress but also experienced large amounts of stagnation. I think this was due to the weeklong spring break smack dab in the middle of the sprint that caused nearly everyone’s productivity to drop to all-time lows. The biggest win we achieved was learning how to and getting our dev environment containerized. A few of the mistakes we made during last sprint, we made again this sprint.

The Good

We made a lot of progress on our board in terms of organizing and giving tasks proper descriptions so we could revisit them later and know what needed to be worked on. While it seemed like we didn’t have a lot to show for the work that we did, we did gain a lot of valuable knowledge that will help set us up completing tasks that weren’t able to be finished this sprint.

The Bad

We repeated a few of the same mistakes from the first sprint by not communicating with each other effectively. While working on completing issues on the board, it became apparent within group that issues were mostly resolved but small portions of them remained incomplete. Because of this our board looked like not a lot of work was completed.

Improvements?

We should be revisiting the board often and make changes where necessary. We need to effectively get better at recognizing when an issue needs to be broken down into smaller issues. Our communicating skills are getting better, but it still needs some work. We came up with the idea that we would do our best work outside of class and use our time together in class to bring each other up to speed on what we have done and communicate what still needs to be done. Lastly, we can make sure we’re using our class time as efficiently as possible by making sure we’re staying on track and not getting sent down rabbit holes of information.

How I Contributed

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/18

I was tasked with creating a drawing feature for the application. This would be used as a means for a test taker to be able to write down what they hear from the proctor. I spent the entirety of my time trying to implement this functionality into our application. At first, I thought I would try to learn how to create this type of function from scratch. After lots of tinkering with PanResponders and InteractiveViews, I realized that this sort of thing would not be as simple as I thought it would be. Instead, we found a project on GitHub called React Native SketchCanvas. This program was being shared under the MIT license and had all the functionality we were looking for. We just had to figure out how to get it to work in tandem with our application. It was around this time that we figured out how to containerize our development environment.

While trying to get the SketchCanvas dependencies into the container, I kept on getting errors from the terminal that were complaining about the components in the SketchCanvas code. It turns out that the software that we use to test our application Expo is not fully compatible with the SketchCanvas and will not recognize certain custom components its comes with. The SketchCanvas seems like it was a class project someone at MIT worked on because it doesn’t seem like there’s any active support in its GitHub repo. While good research was conducted during the sprint, ultimately this task will continue on into the next one.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

For the second sprint, we tried some of the changes we talked about from the first sprint retrospective and some things turned out better than before, but we still have some things we can work on.

Our main concern from the previous sprint was communication, especially on gitlab, and we believe that we have improved because we have been commenting more on issues and stuck to approving and completing merge requests outside of meetings. Up until the last meeting, we were caught up with merge requests and dealing with them before meetings. We made a rule to have merge requests get approved by at least two people before we make the merge. Only a couple issues had to get unapproved because of some problems that some of us who approved didn’t catch, but most of them went through normally. It is also good that we were able to adapt to new technologies that we started working with when it came to test classes and issues relating to automation. Half of us mainly focused on the backend data and test classes while the other half worked on other issues for the backend and API, along with one of the sets of data and test classes. Despite the gap between meetings from before spring break and after the two cancelled classes when we came back, we were able to finish most of the issues that we had for that sprint before the review and only a couple were moved to the product backlog for the last sprint.

The big thing that was a problem for us was the gap between meetings. We were doing some communicating online to stay caught up with issues, but we can improve on that. While we were able to finish most of the issues and got credit for the weight of work, we were rushing near the end to get everything done and had those couple issues we had to push back to the backlog, and there was some disorganization because some of the issues were not being assigned to epics. We have cleaned up the boards and they are all organized now. We wanted to work more on giving better names and descriptions to some of the issues, not just for consistency, but also because some of them were vague or unclear. Lastly, we want to continue our plan with approving merge requests and then merging them outside of class, but want to stay caught up with them because the merge requests filled up for the last meeting of the second sprint and we had to go through each one like how we did before, which was using up time that could be used for other things. We want to improve upon this sprint and have the last sprint be the best one.

As for me and how I did with the sprint and team, I would say I improved from before because I was communicating more online than the first sprint, which was my main focus of improvement. I was more involved in discussions on discord about planning and issues, and I stayed the same for in person discussions because I already getting involved in person. Going forward, I want to try and comment more on gitlab issues if I have any questions.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/13?

Making the data file for the category object that has the methods used in the category endpoints.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/15

Making the test file for category to test the methods I made in the data file.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/16

The endpoint name changes for the backend to maintain consistency.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/merge_requests/46

The changes for the endpoint names where they appear in the API to match the changes in the backend.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Retrospective 2

The second sprint for my software development capstone class was on an honest note a bumpy road. The purpose of the sprint was to start the next level implementation of creating test files using mocha and chai also making sure the API is validated and can be bundled properly. Through the first part of the sprint the team has been very productive on keeping up with the issues we made for ourselves. After Spring break, our productivity started to plummet since we did not accomplish issues the following, we did not have our class meetings. 

As for my team members and I, we have faced greats issues that we started to come across that stumbled all of us. Due to facts of, lack of knowledge, merge requests, and was not able to accomplish all our issues for the sprint. First, when it came to merge request, I admit we have gotten better on how Git operates. But when it came to approving the request assigned to us. We had a pile of request that was not merged and had to spend our class meetings to squash all of time to keep the main repository up to date as soon as possible. Secondly, our productivity has plummeted since our spring break, we did not have to work on anything which was completely optional. But the following week we did not have any class meetings, we did not put in any effort at all and treated it as another extension of spring break. Third, as we gotten more depth of the issues, we did not have any knowledge on how to tackle certain issues. Because the remaining issues were dependent on each other to complete thus since we could not complete them, we had to tackle them towards our next and final sprint. 

Our team has reached a verdict to not stagger on our productivity. Especially when the third sprint is going to be our final one for the capstone class. We decided and wanted to be more proactive and aiding each other’s workspaces when there is possibly something we don’t know or don’t understand. Talked about gathering information from our professor on any recommendations he may give to us to set us on the same page. 

In regards towards myself, I had made good achievements but of course I as could’ve made better improvements that could’ve better contributed to our team. I wanted to learn more about how to implement Mocha and Chai testing. But I chose to do more of the basic parts of the issues to get them out of the way. But for the next I will be taking at least one or two issues that we made to create a more solid test file for all the tests to pass. I will be speaking to my team member that did extensive research to see if he can aid me in how to go about fixing and implement our test files already made gave at least the experience. 

Sprint 2 Issues

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Our sprint went well we wanted to finalize major features on the front end and the back end in order to have the necessary fully functioning for its operation. Our group collaborated on creating sprint objectives that we all agreed were important to focus on in the sprint. We ordered our work items in order from most to least important, which was helpful in focusing on getting the most relevant work done first. This helped later tasks because the issues below were dependent upon other issues being finished first.

Learning lessons from the last sprint, we managed our code much more efficiently this time around. We created a small branch for each time we were going to make a change to the CodeBase. Each one of these branches only changed a small portion of the code or added a small feature. Once we finish this change, we will immediately submit a merge request and have it incorporated into the code as soon as possible. This minimized the amount of divergence from other branches while people were working on their code. We had large stagnant branches that diverged from the other ones in the last sprint, and merging them became incredibly difficult. This time, we did small branches in merge consistently, which kept everyone’s codebase on track. We also set up testing, which still needs further tests, but this allows us to ensure that our changes are not going to break essential features when merged into the main branch.

We had one issue that some issues were dependent on other issues to be completed first. When one individual took longer than expected on an issue that required to be finished first before others could work on theirs, it left some students unable to work on essential features. In the future, it would make sense to re-distribute those tasks to individuals who were not being challenged or add another person to the issue to get it completed more quickly.

As a team, we did a good job at roughly keeping each other member aware of the current task we were working on. In the future, I think we could improve the detail of exactly what we are working on, which would help other team members adjust the priority of which issues they should be tackling. Overall, we did have a good improvement from the first sprint in communication. In this sprint, we also worked well at updating the sprint board and tasks as we finished and moved them onto the next stage.

For the final sprint, our team should work on creating broad goals that we want to achieve and turning those into smaller tasks that individuals can work on. At the end of the next sprint, our goal is to have a working front end and backend that can be deployed within a single docker container, and this will be broken down into smaller sub-tasks that each person can focus on achieving.

As I said for the teams’ comments, I should precisely make it what I am working on more well-known. This will improve the team’s performance because students will be able to choose their tasks better accordingly. I will enhance this during our standup meetings by going into more detail about my current tasks. I did improve over the last sprint and made sure to update the issues board so that two people do not work on the same issue simultaneously.

Issues Completed During Sprint 2

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

Sprint 2 Retrospective

My team is about to move on to our third sprint, so I want to spend some time reflecting on how our second sprint went. Our plan for this sprint was to build a working demo of a Kubernetes cluster that we could deploy to AWS EKS. While we did not get everything done that we wanted, I am happy with the progress we made during this sprint. We got very close to deploying our cluster; the cluster is nearly set up, and AWS EKS has been configured for it. We are prepared to finish our demo at the beginning of our third sprint.

I think for this sprint, we had a much stronger idea about what we actually wanted to accomplish. Compared to our first sprint, this second sprint was much focused more on creating something than on research. It was easier to divide tasks into manageable issues, and it was clear what had to be completed with each issue. Not that the research we focused on wasn’t important, but it was satisfying to be able to apply that research to an actual demo.

In the same vein as the above discussion, having a more streamlined idea of what needed to get done did make it a little more difficult to work. A lot of the issues we decided on depended on the completion of others. It was difficult deciding which issues to take on individually; I felt bad doing nothing while waiting for whatever issues needed to be completed first got done, but in some cases it was necessary. As we complete our demo and move on to focus on communicating with other teams about our project, however, I think this will be less of an issue.

As a team, I think we could still improve our use of Gitlab for communication. I think we were definitely better about it during our second sprint, but our communication was largely remained on Discord, Zoom, or in person. It would be nice to have a more permanent record of our discussions, especially when those discussions are about the work we’re doing and the direction that work should be leading us.

As an individual, I want to take on more challenging work. The issues I worked on during this sprint were pretty simple, and two of the three of them were very easy to complete. I think it would be a better learning experience for myself if I tried to focus on more complicated issues. I also want to get better at communicating with my team. I think I should be talking more to my team members about my progress on whatever I am working on.

Contributions:

Add commitlint to gitlab-ci.yml to demo repository – I added a gitlab-ci.yml file to the repository that will host our demo.

Look into IAM Roles for EKS – In order to deploy a Kubernetes cluster to EKS, it (along with its nodes) must be assigned an IAM role. This post details the roles Amazon recommends using, and it has links to instructions on setting them up properly.

Determine what projects we are using for the demo – We decided to use a simplified version of a frontend/backend/API project for our demo.

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

Sprint 2 Retrospective

Now for sprint 2, much has changed in which the direction, work, communication and more has changed from the previous sprint. There seems to be more communication and a better direction of where we are going and a more complete vision based on the project. There are still questions on what to do and where exactly we are going to end up by the end of the project but hopefully that can be figured out in to coming days. There is also the collaboration between other groups that need to be sorted out.

On what has worked well, we have made good progress on building the API and backend in that there are functioning pieces of code we can work with. The NestAPIMap Joe had obtained from the previous sprint had provided a good starting point for the sprint. The http calls are functioning as they should be and the overall structure of the project seems sound. There was a lot of functionality added to which the API and the backend actually works when previously we didn’t quite have much working at all which is nice. The changes made to the project are numerous and a good sign of work getting done.

On what has not worked well, there is still a feeling of misdirection as we are still new to this kind of work so it shouldn’t be surprising that this is happening. There are parts where people work on different parts on their own and later on do different things than intended in which other people who are working on the same issue don’t know that it has already been finished. The flow of issues from being worked on to done wasn’t quite as fluid as the last sprint as most of them just stayed in process section till the last day in which we sorted them out there.

We could improve as a team by communicating better on the work being done and what is free to do so that way the work could have been more evenly distributed. It felt like some people did more work than what was originally intended/different from what was thought of. There was a lack of usage of the issue board on GitLab which contributed to this problem and that it would be beneficial to have a better flow of finishing issues so that way we know better on what to do or not to do and that there isn’t a backlog of issues all waiting to be sorted until the last day.

I could improve as personally I was also part of the problem of communicating between others on what issues were being done and didn’t quite contribute as much as I could’ve to the project. I feel like I could’ve done quite a bit more contribution work to the backend with the calls and hopefully in the next sprint I dive into some issues and get more meaningful work done. There is the issue of all the other classes I am taking starting to reach their end so I will have to watch for that.

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

Sprint Retrospective #2

Now that the second  sprint of the Naturalization Interview Confidence Environment project has ended, it is time to yet again reflect on the progress that my team and myself as this sprint’s Scrum Master have made thus far. Moreover, it is also time to reflect on what went right on wrong during this sprint, both in regard to what we as a team decided to improve upon based on what we discussed during our first retrospective, as well as what new obstacles may have shown up during the second sprint. It is important to note that in this sprint, unlike the first, the team had a sense of direction as to what needed to be done. For comparison, during the first sprint we were more concerned with determining what development framework we would need to use for the project while in the second sprint we had somewhat begun the development process of the project as well as creating the infrastructure for development. Though some progress may have been made, this sprint did not prove to be as fruitful as the last.

In this sprint, we as a team had planned on working on 36 issues across 5 epics. Moreover, for this sprint, the main team was separated into two sub-groups with one working on creating the application itself while the other worked on creating the Docker development infrastructure needed for future development. The application development group, of which I was a part, was tasked with implementing the following functionalities:

as well as other functionalities that would be necessary, such as ways to navigate between the aforementioned functionalities. I was primarily tasked with implementing the reading portion of the application (as linked above), meaning I needed to implement the necessary functionality for a user to be able to see previews of the questions that are to be included in the application, as well as interact with each question separately. Though I was tasked to implement a specific functionality, I was still expected to help my teammates of the application team in the case they needed assistance with their own task, as well as provide support to the Docker infrastructure team.

          Though, admittedly, the breaks that occurred during the sprint contributed to hindering the structure of our productivity, as well as certain tasks taking much longer to work on than we had anticipated, there was still some progress regarding the infrastructure aspect of the project which continues to be worked on and improved by the responsible team members. Some problems that we had noticed in retrospect are mostly related to our management of time both during and outside meetings. As a scrum leader I still had issues managing our time during meetings such that there was a balance between allowing all team members to express themselves fully as well as using the meetings to outline what progress has been made and what progress needs to be made. Moreover, though we as a group acknowledged that documentation is extremely important, there was still lack of proper documentation and clarity in issues, which contributed to the improper time management of our meetings since there was more focus discussing what each new issue actually meant, thus meeting discussions wound up being somewhat disorganized. On a positive note, however, our approach of “Divide-and-conquer” from last sprint was crucial in helping the team establish who would do what tasks, either regarding the application or the infrastructure. Moreover, there has been substantial improvement regarding documenting what is being discussed during meetings, with certain issues having the appropriate context needed to ensure proper communication of our goals and progress between team members.

          As detailed above, while this sprint had its flaws regarding productivity and time management, there was still some progress made regarding development and infrastructure. While we all, as a team, acknowledge that some mistakes from the first sprint were still present in the second sprint, we are all still willing to learn from such mistakes and improve our own productivity and communication.

Direct links to issues:
1) Build a page that shows previews of the questions for the interview: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/28
2) Learn how to use commitlint/conventional commits for the Application source code: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/13

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #2

For our second sprint, I think our group had a lot of ups and downs. At the start of the spring (before Spring Break), our group was very productive. Before break, we divided our group into two subgroups, three people working on the programming portion of the project (Sofia, Emmanuel, and I) and three people working on constructing a Docker container (Pernesso, Joao and Dylan). Early on, Dylan was able to get a Docker image and container working for our project. So, the Sprint was off to a strong start. During the last class before break, Sofia, Emmanuel, and I managed to break up the programming portion of the project into separate parts and assigned each part to a different person. So, each one of us knew what we had to work on over and after break. Some of us in the group had made plans to meet up over break using Discord to work on the project over break, but things came up and not everyone was able to meet. Sophia and I managed to work over Discord during break and I think we got a lot done. We did a mix between going over issues on our issue board and actually programming. For example, one of the issues I was going to work on over break was the Oath of Allegiance page and Personal Information page.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/13

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/31

Originally, we had these issues as one issue which we decided did not really make sense because we were building two different screens. After an extensively discussion with Sophia, we also decided that the Personal Information page should go into our product backlog because if the purpose of our application was to just let people practice before taking the exam, then adding a Personal Information page does not really much to the functionality of our application. If the application was to simulate the exam, then adding a Personal Information page would make a lot more sense. So, we decided adding a Personal Information page was more of a luxury item that we could implement in a later Sprint if we have time. After our meet up, both Sophia and I documented what happened and our decisions on GitLab. So, in the beginning of the Sprint, we had decent documentation. It was what happened that everything kind of went south.

While I think our documentation was fine before and during break, I think documentation was one of the areas that fell apart the most after break. After we came back from break, we never followed up with one another on what we worked on during break or the week after break and so it was difficult to what was or wasn’t getting worked on or even what already done. Another issue that we had was we did not adjust the weights accordingly. When we initially made the issues in class before break, one of the things that we talked about was how for some of the issues, we did not know how to give it a weight because the issue may have been too broad, or we don’t know how to break up that specific issue. So, we were going to break some of those issues over time during the Sprint. This did not end up happening and our weights were off.

What I really to work on as an individual is working on a team. During this second sprint, I talked to my teammates a lot less than I did during the first Sprint. I just worked on the issues that I was assigned to and did not check in with anyone from the group unless I needed their feedback. For example, another issue that I worked during this Sprint was creating a UML diagram.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/1

This was one of the few times I checked in with my group. I made two different diagrams. One simple diagram and one where I was trying something new and wanted my group’s feedback. So I feel like I need to work on checking in with my group more to see what they are working on and let them know what I am working on.

Another thing that I need to work on is writing issues as they come. Sometimes when I am working on an issue, I encounter more issues and I wait until the end of the sprint to put those issues on the issue board and forget about it until I talk to someone about it.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.