I am in my third Retro Scrum since joining the team. This is the first retro that I will not present. This paper is centered around items that I look forward to approve on for future Retro Scrums.
A few “bugs” I learned from my third Retro Scrum:
- The UI is key for our users. I spent majority of my implementations on logic and functionality. At the time, my features were functional but needed CSS for aligning with the correct UI design.
- Do not take on more tasks/bugs for Sprint. When creating a new UI, current bugs were put on hold as most of my time was spent on the new UI. New UI means new features, new logic, new components, new libraries, new CSS. Prioritize the new UI with other tasks is key for a functional app as well as making progress.
- To make point 2 easier, each bug/Jira ticket should be a new branch. This will help if a recent MR you sent breaks and can easily be pulled back if using this convention.
- Ask Questions. This one I left last because it’s not one for me but for anyone else reading this article. You have a team that shares information to create a final product and/or feature. Communication is key to success. Hopping on a Zoom or Team calls to resolve any uncertainty can go a long way and save a lot of time.
Hopefully after reading, this will help with any questions you might have on Sprint Reviews/Retros. Each company model might be different but the three bullet points can be useful as I will take each into consideration.
This is a short article but felt needed if anyone is going through the same. It’s okay and build on my weakness to become successful.
