Relevance to the Concept
Without a Scrum Master, there would be no agile development framework. The development process during this project would be much more hectic and no tasks would be tracked or accounted for - there wouldn't even be any tasks to refer to in the first place! Rather than flying blind and adding unnecessary stress, a Scrum Master implements a steady and reliable plan of what needs to be done and ensures other team members can focus on a couple of tasks at a time rather than trying to juggle everything at once.
Technical Research
What is a Scrum Master?
Summary
Details 10 crucial tasks that a Scrum Master is responsible for carrying out. Also emphasises the important differentiation between a Scrum Master and other existing roles like a product manager or project manager.
Scrum Project Management: Advantages and Disadvantages
Summary
Reiterates points made in the previous research resource and then details the advantages and disadvantages of using the Scrum framework, including increased efficiency and the need to be cooperative and motivated. Also outlines some steps in the Scrum process.
User Experience and Scrum Teams in the Games Industry
Summary
Details how different games development companies have different methods of implementing Scrum in their development process, and is rarely done purely. Most companies tend to take on morning meetings and the backlog concept and agreed that Scrum was adaptable and inclusive and collaborative, but also argued that the idea of having a shippable product for every release is difficult and that different member personalities led to hassles during collaboration.
Backlog Process
Creating the Backlog
The first thing that would be decided during at stand-up meetings at the beginning of a release was the plan for the end of the following release - this would include any extra functionalities we wished to have completed, bugs we wanted to fix, or changes made to existing features based on feedback received during the previous release. From this plan, backlog items would be created to accommodate for what we wanted to have done come the end of the release. Of these backlog items, some epic stories were able to be created, as some backlog items would be similar enough to be part of the same goal. Each backlog item would then be given an appropriate description and tag to emphasise its priority, and assigned to one of the team members with specialisms that made them most suited to each task.
Epic Stories Backlog Items Backlog Info
Story Points + Hours
Once the backlog was filled with all the items we wished to complete for the release, we then got onto planning hours and story points for each item. We started with hours, since this would then feed into story points, and for each task the team member that would be taking it on gave an estimate of how long the particular task would take them to complete, based on previous experience and knowledge of how to go about completing the task. Once this was done, story points could be allocated to each task; for this the team played planning poker and gained a general consensus over each task's story points, with the assigned member having more say over the decision should there be multiple answers given and a discussion had to be had.
Scrum Meetings
The team partook in stand-up meetings at the beginning of every sprint to allow discussion to happen regarding what was completed last sprint, what went wrong and what would be completed during the next sprint. These meetings would last approximately 20 minutes and usually included some extra discussion around general progress and concerns regarding team velocity or feedback on the project. At the end of every release, stand-up meetings were also held to create the backlog for the next release and prioritise backlog items once they were created.
Release 1 Breakdown
Release 3 Breakdown
Release 2 Breakdown
Release 4 Breakdown
Challenges
- Keeping my team members on track and reorganising what story points are in or out of a sprint depending on whether there's issues during a sprint that prevents someone on the team from working on their story points.
- Maintaining team efficiency: While passion isn't the problem, external issues sometimes get in the way that can reduce our velocity in any given sprint. So I try to get the team back to where we should be in the following sprints to ensure we don't fall too far behind where our progress was planned to be. With a couple reminders and check-ins with each team member, I've been able to ensure everyone's ready to get back on track and put the extra work in after things go awry.