Hello again!
This week I will be writing about how our team works during the game production, which we do by follow the Scrum framework. Scrum is an agile framework especially tailored for software development, so naturally it works very well for game production as well. When working with Scrum, the goal is to often and continuously produce increments/a shippable product, in this case working versions of the game. To do this, we work in sprints. Under normal conditions a sprint lasts between 2-4 weeks, but since our project is only 10 weeks long our sprints lasts for one week.
At the start of each week, and each sprint, we have a sprint planning meeting. During this meeting we decide what we want to accomplish this sprint, and then we pick features from our backlog that will help us achieve our goal. We make sure that each team member accepts the tasks given to them, and we always strive to get as close to 20 hours of work each sprint as we can. At the end of each sprint, which is every Friday, we meet for a sprint review. During this meeting we go through what we have done this sprint, review what went well and what we struggled with, and the group as a whole reflects on how the sprint went overall. For our current sprint we are working on implementing all of the features we want the game to have for the beta the 5th of March.
Personally I favour Scrum over other approaches. I think it’s partially because it suits my individual style and work ethics, but also because I see the results from developing a game using Scrum. This framework has allowed team Devourer to be very efficient, much more so than when we designed our concept document last semester. However, I don’t think we have followed the framework 100%. The reason for this is that when we have our sprint planning meeting to decide what features to work on that week, we simply pick what we believe we need, without considering the user stories. Why do we not just make our lives easier and pick a user story each sprint, I hear you asking. Well, honestly we didn’t actually have any user stories in place when we began our first sprint, and since then we didn’t pick up the habit of using them. I also feel like the team’s understanding of user stories was fairly limited when we started out. I don’t think this has caused us any significant problems, and it hasn’t affected our work efficiency (so far!).
Devourer Dev Blog 
Hello Magdalena! I am pleased that Scrum seems to be working out well for you and the rest of team Devourer!
Your blog post provides a good introduction to what Scrum is, and I can imagine that a reader with limited understanding or experience of Scrum would be able to read this post without feeling too lost in the subject matter.
Whilst your post is sufficient in explaining some reasoning behind the decision to not use User Stories, I am left wanting for a more detailed description about the other decisions you have made when working with Scrum. You mention the Sprint Plannings and Sprint Reviews, but don’t go into any detail on how those have impacted your development. Here I wish that you would have included a more detailed description of how you set up these meetings, and most importantly, how your group has reacted to this style of working. It would give your post more value if you tried to further analyze the difficulties and opportunities that Scrum brings with it to a relatively inexperienced team.
All in all, you post is well written and fulfills the standards of the blog post assignment as far as I can see. With this high quality in writing in mind however, I would have loved to see a bit more reflection about impact and some more pros and cons compared to your previous workflow instead of just stating the results of using Scrum for your current project.
Kind regards,
Anton Berglund
LikeLike