Sprint 1 - Retrospective

[Nintails-TF]

Post your successes/failures on what happened during a sprint.

[Nintails-TF]

• I had problems keeping up with branch naming conventions and improperly named some of my branches when documenting things.

• I also had issues where I would assign people the wrong tasks

• With the API team and the back-end team we had merge conflict over file names and sending PRs that overwrote files names. This caused issues with our version control and blocked us. We resolved this by

• Scrum master helped Alex find a mouse when needed, helped a ton with optimising workflow.

[Nintails-TF]

We should of done more planning about the work that we should have done during sprint 1. A big problem we ran into is that - "How do we know that we are done working during the sprint." Basically have a definition of done for our sprint 1 for each of our areas that we are working on so we know what we are doing.

We ended up spending alot time moving things from the product backlog to the sprint backlog.

It would of been good to estimate on how much time things would have taken using planning poker.

[Nintails-TF]

We had Alba, Lucca and Ben who where all sick with fever, so this has impeded our progress in developement. They have been helping our remotely but things have still been tougher for our group.

[Nintails-TF]

Hosting a website shouldn't of been linked to every user-story. Since it blocks complete user-stories from being closed.

[Nintails-TF]

I wanted to help Lucca with DevOps since it would of sped up the sprint greatly and prevented us from being blocked for a long time, having linting and automated checks up faster would improve code quality and standardization.

[Nintails-TF]

Retrospective Notes:

• Take more time working on slides during the week, so that we can have a better presentation that is within the time.
• Bit more casual meeting.
• Be more punctual with time and getting into meetings at a good time.
• More discussion about when people are in.
• Have a more clear time on when startups are.
  • Stand up meetings are at 1pm.
• Workload is managable.

The two big things are:

1. We need to focus on how we can deliver value to the NCR.
2. We need to make sure that our development tasks relate to user stories.

INSPECT how the last sprint went about people, relationships, processes, and tools

• Our processes and tools were very effective, Mike was rather happy with our use of Github
• API/DB Team (Ben & Finnbar) - Pair programming also worked very well for us, and this is highlighted in the marking sheet for this 2nd Sprint
• Back-end Team (Lewis & Lucca) - We had some issues with communication with the API Team & confusion about the direction of the project in the first 1-2 days on our Sprint, which we will improve this week with more thorough planning
• SCRUM Master (Adam) Our main criticism of our Sprint Review was that we were focusing too much on 'developer talk', rather than value to the customer. We'll be more careful this Sprint Review, and take all of Mike's notes into consideration when creating our presentation

IDENTIFY and order the major items that went well and potential improvements

Went well:

• (Product Owner) - GitHub usage was exceptional, Mike seems really impressed with this, and we should continue to work how we have been in terms of our GitHub use. Backlog organisation was also very good, and easy to read. Having our issues and User Stories in the same Backlog can be slightly confusing, but we've been using label filters so we can sort by User Stories. This works better for us as a team, as we like to see our separate tasks / issues in the Sprint Backlog.
• (Development Teams) Pair programming has worked really well, allowing us to collaborate effectively and get things done very quickly and efficiently. It also allows both developers in the pair to have a complete understanding of their elements of the project. Discord communication was highly effective, allowing us to continue working with each other when member's were sick and couldn't work in the QMB
• (SCRUM Master) Our code reviews were really effective, and helped us have a better understanding of what each person within each team was actively working on. Also our daily standup's were very thorough, and gave everyone a solid understanding of what each team was working on, and what was to be completed by the end of the day. A good opportunity for teams to discuss collaboration

Potential Improvements:

• More planning, especially with time estimates (T-Shirt sizing)
• More focus on 'customer value' in the Sprint Review, look at Mike's notes together as a team

OUTPUT actionable and committed improvements to process As an alternative

• Spend an entire day planning, and creating new user stories for our new client requirements (and our 2nd Sprint in general). Make sure every issue has a value, risk, MoSCoW value, and T-shirt Size
• Work on the Sprint Review throughout the Sprint, rather than creating it after the development is complete. We perhaps didn't give ourselves enough time last Sprint to create our review, and didn't prioritise our Sprint Review enough
• Ensure that our development tasks relate to our User Stories. In general, our development should all be focused on adding value to the project, as this is extremely vital to the Agile methodology