In this blog post, I will reflect on the third sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with descriptions.
One of the things that worked well for me personally during this sprint was the quality of documentation that I had created. I would say that my documentation was consistent from beginning to end for sprint 3. For all the work and decisions I made for this sprint, I made sure to document it for my current teammates but also for the next students who would be taking over this project. Another thing that worked well for me this sprint, was creating a document with specific goals that I wanted to accomplish prior to each class. I regularly checked in with this document through sprint 3 and it served as my personal issues board. I kept updating the specifications of my issues but the overall gist of the issue remained intact for the duration of sprint 3.
For things that didn’t work that well in this sprint, even though I consider sprint 3 to be my most productive sprint, I also feel like I did not deliver enough minimum viable products that possessed incremental improvements. While I did produce a minimum viable product for updating our landing page, that soon got quickly incremented with another teammate’s commit. What I was really hoping I would be able to crack was creating an interactive drawing page for the writing portion of our application. While I made several attempts in creating this feature, they were all ultimately unsuccessful in producing a minimally viable product that improved on the pre-existing code.
As far as what we could improve on as a team, one of the things that I think could have made us even more successful would have been having a conversation about what we wanted the minimum viable product for sprint 3 to be. I think we knew all the work/issues that needed to be done for this sprint and we went full steam ahead, however, we probably could have benefited from taking a mental snapshot of where we were at the end of sprint 2 and where we hoped to be at the end of sprint 3.
When it comes to changes that I can make to improve as an individual, I would like to address my previous issue of what I don’t think worked that well for me in this sprint. Next time, I think I should focus on taking what is already present and making one minor incremental improvement before moving forward with an exploratory phase to create a major improvement. My initial increment doesn’t have to be much, but it would allow us to say we delivered something different from sprint 2. By doing something small and simple first, I can then focus my efforts on riskier experiments. If these experiments work out, the risk would have paid off, but if they don’t work out, I can fall back on the safe, small incremental improvement I made.
Links to evidence of activity on GitLab with descriptions:
- What I essentially did for this was replace the “We want pizza” landing page to one with two separate buttons. One leads to the “Writing Portion” of our app and the other leads to the “Reading Portion” of our app.
- I asked for clarification on why an issue was closed so that it is documented.
- I explained my process with getting expo running for me (which is different from how one of my teammates was doing this).
- I pulled and checked out the code per my teammate’s request to make sure it worked on my end.
- I pulled and examined Emmanuel’s code per his request and then made some exploratory attempts to implement a writing feature.
- I documented a potential idea for our issue with implementing the reading portion of our application.
- I created an issue with some notes for whoever starts the process for this issue.