Scrum and how it has affected Umibozu game and my own development
|
Scrum, simply described is the idea of making a list of what needs to be done (product backlog),, have teammates pick their tasks from this list (sprint planning and sprint backlog) and then perform them during a period of time called a sprint, the time of that sprint can vary, but is usually longer than a week, but a week is what we have been working with (and has been working well, I would say). At the end of this sprint the team reconvence, and reflect what has gone well and what hasn’t, and, if needed, what parts of the products should be changed. After this, another meeting is held assigning new tasks. During these sprints there are also daily checkup meetings held made in order to have the team updated on everything in the project and not just their own work. This makes Scrum an efficient and adaptable work tool, that gives the project a possibility to change during its course – and well fit for small scale game productions.
(Picture taken from google image search, https://www.scrum.org/resources/what-is-scrum) One thing that has proven to bea bit harder with the scrum is the assigning of tasks, and, exactly, how long a task will take to accomplish. Since almost all my tasks involve graphics, I have to know how long it will take to paint something, this proved very hard when I had to make animations to the game, something I was very new to, and didn’t know how long the process would take. As it was, it took a lot longer than I thought to make the first animations, it took three sprints for the two first animations I made (an enemy swimming, and an enemy attacking). Something that made me have a lot of unfinished tasks at the end of each sprint in the beginning of the project. This is still something I am figuring out, and I often take on a bigger workload than I can finish in a sprint.  |
