Category Archives: sprint

Sprint 2 Retrospective

Introduction

As we conclude Sprint 2, it’s essential to take stock of our journey, examining both our successes and the challenges we’ve encountered along the way. This sprint, our primary focus was on scaling up productivity and initiating the UI development process. Despite its longer duration compared to the previous sprint, Sprint 2 felt back-heavy due to delays in commencing frontend work until we obtained access to the new template.

Challenges Faced and Lessons Learned

Both sprints presented us with unique challenges, contributing to our team’s growth and development. One significant challenge in Sprint 2 was the unexpected complexity encountered while coding a UI component. Initially deemed a simple task, unforeseen changes in the source code necessitated extensive adjustments, resulting in delays and frustration. However, this challenge provided valuable lessons in flexibility and adaptability. By grappling with the intricacies of the component and adapting to evolving requirements, we honed our problem-solving skills and gained a deeper understanding of UI development.

Another challenge stemmed from the weight of certain child issues, which had a more substantial impact on our workflow than initially anticipated. This highlighted the importance of thorough planning and assessment when breaking down tasks and allocating resources. Moving forward, we recognize the need for a more nuanced approach to issue prioritization to ensure each task receives the appropriate attention and resources.

Team Dynamics and Communication

Effective communication emerged as a cornerstone of our approach throughout both sprints. We found that tackling problems collectively as a group significantly eased the resolution process. Whether through online discussions or face-to-face meetings, open dialogue and transparent communication channels were maintained, ensuring alignment and informed decision-making. We intend to prioritize effective communication, proactive problem-solving, and meticulous planning in future endeavors.

Strategies for Improvement

Team Improvement

  1. Keep a consistent schedule: In hopes of avoiding a repeat of the last sprint where everything was stacked at the back of the sprint, it would be beneficial to manage our time better as a group with a more consistent meeting time.
  2. Division of Labor: We continue to ensure that one person does not get stacked with too much to do while others get left with little to work on.

Personal Improvement

  1. Frequent Check-Ins: In realizing the significance of team alignment, I commit to checking in more frequently with my team members. By maintaining regular communication and seeking feedback, I aim to ensure that our efforts remain aligned towards our common objectives throughout each sprint.

Moving Forward

As we look ahead, we are committed to leveraging the lessons learned from Sprint 2 to inform our approach in subsequent iterations. Documenting challenges, solutions, and key takeaways in a “lessons learned” repository will serve as a valuable resource for future sprints, enabling us to anticipate and mitigate potential obstacles more effectively. With a shared commitment to continuous improvement and a supportive team environment, we are confident in our ability to overcome challenges and achieve our goals collectively.

Links to Activity on GitLab

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint 4 Retrospective

Sams Ships (12)For this sprint wrap-up, we discussed how we are trying to move on based on our team planning meeting. One of my teammates, Kristi, along with Professor Wurst, tried to check out an idea they had and continued to bounce ideas back and forth with one another until they came to a conclusion.

Overall, I’d say we are continuing to plan out our next steps and work on something new. A new development was a suggestion by one of my teammates based on what we already have to work with. The suggestion was that we should wait for the other group to push what they need and then we can seamlessly build upon it. If the other group (who are working on the sidebar and navigation bar) add their work, it would help us have a better base.

We have to carefully analyze how the components are going to go together and get through to make sure that they are not just getting thrown in. If we plan things out more, it will make the process more efficient. I think taking a step back to look through angular was helpful because it allowed us to learn something new at our own pace. It’s nice to not have to rush on what we are doing; especially when the concepts are newer. This will help us deliver something even greater for our client, who is Greg from AMPATH.

There is also the approaching team presentation that we are going to be focusing on to explain our work and what is happening. I think it will mainly be focused on the search bar and our experience with learning angular or the concepts that introduced us to it.

On top of what we have been doing, I have been continuing looking up resources to learn more for our project. I think Codecademy is a good reference for learning AngularJS, https://www.codecademy.com/learn/learn-angularjs. It is actually one of my preferred sites for reviewing programming languages to sharpen up on things I may have forgotten or for learning new ones in general.

It has been a great experience being able to work with a solid team so far this semester. I wonder how much we will accomplish by the end of it! I think learning about communicating within a team is so important, especially since we will all be graduating very soon and entering roles that require consistent communication.

Overall, the only thing I would say I would have proceeded to do differently is come up with another way to “work smarter not harder” when it came to figuring out the process for the search bar. There were not necessarily any fails because our continued work dealt more with the planning behind the work instead of testing to see what worked for us. I am very excited to continue moving forward with this project in the few weeks we have left!

Some advice for others who are going to work on things includes:

  • Having an open mind on what they would like to do because things are always changing
  • Understanding what the client wants is important because at the end of the day, they will be the ones who need to use this software
  • Try to make sure teammates are on the same page with you on what is happening that week

 

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