This week’s Sprint was relatively uneventful due to a combination of reasons. First, due to the weather, we had snow days which interrupted our meeting. Second, we had issues communicating with the Ampath people, and we had classes cancelled for a week, so there were no concrete assignments for us to add to the product backlog to create our definition of done to deliver value. Finally, and this is a more personal reason, I caught a stomach bug so I was unfortunately not able to show up to the few classes we met up in.
Even though we weren’t able to produce any solid units of work, we still kept our team on track for our Scrum related tasks such as our stand-ups and kept our overall plan pretty solid. We are still in the process of completing the tour of heroes tutorial for angular, as well as installing and finishing the tutorials for the two testing frameworks Karma and Protractor.
After we began that, we took a look further at the tutorial for Karma, and installed the code into our computers. The Karma tutorial is relatively short, although we are expecting to have to allocate some extra time to researching about the Jasmine framework and syntax that both Karma and Protractor use in their testing commands. One thing we noted while looking through the tutorial is the fact that Karma tends to look similar to junit unit tests, so we are hopeful that Karma will feel somewhat intuitive when designing our unit tests.
The first major decision our group made based on the tutorials was that we are going to go with the tour of heroes for brushing up on our angular skills. We are allocating the most amount of practice time to completing the tour of heroes because we all believe that brushing up on our angular skills will be the primary force behind our whole project, while we can learn the testing frameworks slightly easier, is what we are hopeful for.
In light of the fact that our group was not able to produce any direct value this sprint, I still believe that we will be an efficient team. Even though we had no tasks, a few of our team members kept us on track for due dates of stand-ups, CATME surveys, and blog posts. The rest of us kept on track for preparing for when we had work to do so everyone in our group would be ready to hit the ground running.
So what I learned is that even though we did not contribute anything to the project during this sprint, I do not believe that we need to change anything about how we proceed or group organization or splitting of tasks. I am happy to have learned that team roles are naturally starting to develop due to the personalities of our team members, as one of us is adept at time management and keeping the group on track, while some of us can help out more with technical skills and troubleshooting skills. That is great because we will have less difficulties.
From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.
For my second sprint retrospective, there is something I would like to reflect on in terms of a change to my first sprint conclusion. It turns out my build environment was not completely set up properly so I had spent some time with assistance from my teammates on configuring that. I would like to note that I have a MacBook so that made things a little different to work our way around figuring out what to change or test out. A very helpful link was from a question someone asked on 
which shows how we were able to keep moving and working despite a roadblock that we could not control. It is very relieving to know we are now all on the same page and are working on moving forward together to contribute to the AMPATH system from now until the end of the semester. Who knew something could be more relieving than finally seeing the login screen after the ng command and going to the localhost url.