Outline of Our Scrum Framework - Jacob1225/pufferfish-minecraft-mod GitHub Wiki

Using modification of Scrum agile framework
Sprint duration: 2 week
Stand up meeting: 1/week, Tuesday after class on Zoom
Communication methods: Discord and meetings throughout the week in smaller groups
Pair programming (paired based on experience)
Allow roles to be switched based on preference (during later iterations)
Every team member contributes to documentation

Main roles:

Scrum Master (2 people): Collect user stories and create Jira tasks. Discuss with team to create a Product Backlog. Discuss with team to prioritize items for the Sprint Backlog. Organize scrum meetings and make decisions on issues blocking workflow.
Developer (6 people): Set up the development environment. Implement the features described in the Sprint Backlog.
Tester (2 people): Set up the continuous integration and testing environment. Write the necessary tests for the features.

Deciding roles:

Roles were decided based on the results from each member filling out the survey. New members would also fill out the survey when onboarding.

Why Scrum was a good choice?

We decided to use Scrum as a reference for our group framework because we believed it fit the best with the project and our team members.

Quicker release of a useable product to users and customers

It is a good fit for the project because we need to develop a product in a relatively short amount of time (~ 3 months). Non-agile methods like Waterfall would mean that we would invest too much upfront time on planning and most likely not have a useable product at the end. An agile framework would enable us to start code development immediately after a single sprint planning meeting. Ideas would then be added to later sprints as we develop the code and gain more understanding about the product.

Our team also has a diverse skill set that enables them to learn quickly by doing and good communicate with each other when they encounter any issues.

Adaptability when facing blockers

The advantage of Scrum is that the team is very adaptable and when there are issues that occur, it is possible to modify features or approaches in order to maintain a high quality product. We found that our team encountered several main issues where we required agility to resolve the issues. The most notable issue was the Forge version issue. Originally our team decided to develop our mod in 1.12.2, however after 2 sprints we realized that many of the features we had planned for the sprints could not be completed on time because of various difficulties (ex. testing, GUI screen, Minecraft interactivity). Upon realizing that this was a blocker, our team immediately considered Forge 1.16.5 and started working on the new version right away to test whether it would resolve some of the issues we were having with 1.12.2. Because of this adaptability from the team, we were able to move forward from this blocker and have substantial results by the next Milestone.

Prioritization of features that would provide the consumer with the most benefit

The agile approach to development is to prioritize the implementation of features that would be immediately usable by the consumer. This means that we spent less time planning architecture and developing frameworks, and more time was spent on implementing front end useable features. Overtime, we would be able to go back to existing features and integrate them with other features and refine the code framework even more. However, since we took the approach to prioritize user story features, we were able to provide one of the most complete usable products out of the teams.

Customer feedback

Since we would have a couple useable features implemented after every sprint, we were able to integrate customer feedback into the sprint planning. This consisted of showing our friends our working Minecraft mod and asking for their input and what other features they would like to see. Then, these feedback and user stories were discussed during sprint planning meetings and added to the Product backlog. Eventually, this helped our team come up with more ideas outside of our initial ideas. As well, our team had limited knowledge in Minecraft and by discussing with actual players of the game, it enabled us to gain a better understanding of what the players could want.

Pair programming

Although Agile does not formally implement pair programming, we took inspiration from Extreme Programming. We found that our team dynamics and personalities would fit well for pair programming. We have about half the team with a lot of work experience in Java programming, and then the other half had slightly less programming experience. To enable everyone to fully participate and gain more experiences, we paired a more experienced person with a less experienced person and also took into consideration the schedules and personalities of the pair when forming them. Reflecting back on this discussion, it was a very good idea since it helped with team morale, allowed more collaboration within the team, facilitated communications and follow ups when people could not make it to a meeting, and helped with code review.

Documentation

In Milestone 1, the approach to documentation we decided to take was to prioritize development and leave the documentation to afterwards. We found that this was not the best approach since this meant that during development, some overlapping concepts would need to be re-explained to other group members instead of redirecting them to a documentation of the concept.

For Milestone 2, since the development started to have more steady process, we took a documentation-first approach. Document decisions and planning first and as well during the development process. This helped with having better information flow among the team.