This sprint was a very important one considering what we had sought out to accomplish. In this sprint, we wanted to add many functionalities and since it was the last full sprint before the end of the semester, we wanted to address all the major functionalities we felt needed to be added before we called it a semester. Some of these tasks that was being addressed this sprint was : 

  1. Updating Offline Track Refresh Time.
  2. Documentation of work that was completed 
  3. Test Cases – UI Checkbox Test 
  4. Backend Functionalities. 

Most of the documentation was done by our team captain, since he had the most understanding of all the moving parts that was involved in the program.

What was Accomplished 

Of the tasks that was set out to be completed, we were able to complete the offline track refresh time and also the backend functionalities of the program. To make things more clear, we also documented a list of classes and files that we touched / edited and also draw a diagram of how we envisioned our additions and modifications to function within the application. Backend functionalities was tricky but we were able to write modify existing methods and function and also wrote new methods that would aid in completing the requested task. All this work was again documented and revised.  I believe the most challenging tasks through out the sprint was coming up with test cases that would evaluated and affirm the functioning of the proposed written code. I was personally in charge of this testing. From deciding to address testing, i was able to dig through many codes and files that we later had to review and revise. Every code we wrote needed some sort of testing module that would verify its status and would be used to troubleshoot should we find have any issues in the future. 


After this sprint, i conclude that testing although may not seem like it, is one of the tedious tasks of writing code. In order to write efficient and proper test, you need to be able to understand the logic thats already being implemented in the code then reverse the thought process and develop a new way that you can verify that the task got accomplished.  I realized that not only do you need to be able to read and understand code efficiently, you also need a creative edge that would be used in coming up with test cases and scenarios. This is because unlike coding, often test cases and implementations are unique and does not already have a laid out methods to get this accomplished. Coding requires pose and originality but i believe testing adds a touch of creativity to this paradigm. Overall it was a good sprint and i think we were able to communicate better and get a lot done. 


Sprint 5 Retrospective


Once again, i think we had a successful sprint this round. Once again we increased team communications and continued to form better team bonds. This is specifically because this sprints task required us to consult each other for things we have expertise in so we could build together what we needed to build. I this sprint we took upon quite a few tasks to get accomplished. Some of these tasks included taking the offline checking of the current ampath build and moving it to the outside of error checking and by doing that, figure out a way to fix the OnlineTrackerComponent bug we found in the program. Another that that needed to be done was establishing communication mediums with the AMPATH group and addressing some development issues we wanted to discuss with them. We needed to know if we had to worry about storing secondary and additional user login credentials offline. Knowing this would prove pivotal to our developmental Sprint. We were also able to create a backend of the new UI we were implementing using Balsamiq. Another task that was sought out this sprint was to update the HLD with local storage approach and add a checkbox to the user settings page to give option to store credentials locally. This task was taken by one of our teammate and although they were working on it alone, collaboration between the individual groups was needed because there were a lot of dependency issues. 


From this sprint i learnt that sometimes not all the task we seek out to accomplish during the sprint planing is able to make it through the entire sprint. During the initial sprint planning, we had a talk about implementing a local database that would store and keep user credentials so for the few days into the sprint i began building the database base but as the sprint progressed and our team was able to communicate with the Ampath people, we realized that that extraneous part of building the database was not necessary needed. Instead understanding the encryption method of the user credentials would better suit us in our task of creating an offline login. Needless to say, i had to clear the drawing board and start again.

Lesson Learnt

Overall i felt like this was the biggest lesson i could take from this sprint because i started building and spending time on it but since it was ruled out as not necessary, it almost seemed like i had wasted that sprint time. IT made me realize that in this software development industry, the product owner and the businessman have the keys and unless you ask them for it often you will develop and code in a backdoor without even realizing that your design grew old in the specifications. Establish a good and frequent communication method with the people overseeing the demands and design of the project serves as key in become a good program develop. It makes no sense to design and solve a problem with no longer exists in your scope of work.